Option to not use UTC time offset in ArcGIS Online

01-22-2013 02:21 PM
Esri Contributor
Is it possible for ArcGIS Online to have an option to display date fields using local time instead of UTC time?  It is fine to store the dates in UTC, but it would be helpful if dates/times could be displayed in local time.  Perhaps AGOL organizations could have a time zone setting that organization administrators could opt to set.  This would be especially helpful for users/organizations that don't have cross-time zone issues to face, and want to see times and dates in the only time zone they ever work in.  Thanks.


Another option is to use Arcade expressions to change to UTC. I have done it today ( ) and works fine!


Also I have formatted the date to show it as the customer wants (I work at Esri Spain):

Day(ToUTC($feature["FECHA_FICHERO"])) + "/" + Month(ToUTC($feature["FECHA_FICHERO"])) + "/" + Year(ToUTC($feature["FECHA_FICHERO"])) + " " + Hour(ToUTC($feature["FECHA_FICHERO"])) + ":" + IIf(Minute(ToUTC($feature["FECHA_FICHERO"])) > 9, Minute(ToUTC($feature["FECHA_FICHERO"])), "0"+ Minute(ToUTC($feature["FECHA_FICHERO"])))



Equivalent to ToUTC() is another function called ToLocal()


This is great when I'm uploading the data for the first time and I don't ever need to touch the feature service again. However, I run a script to delete and re-add features every day using JSON operations on the REST services. The new features added are not converted to my local time.


Really need the option to turn off the UTC conversion so we can display the correct date when appending new data, otherwise we have to manually add the UTC difference to the table before appending. Please make this change for the next version.

by Anonymous User

I'm having this exact same issue. Have you found any sort of work around for it yet?


Hi Brandon, I didn't find any workaround other than just creating a new field and adding enough hours to it to make it appear the next day on AGO. Not ideal...

by Anonymous User

We're still wanting it apparently


I agree with this idea. I can understand why the existing set up may work for multinational companies but local governments or single-location enterprises need a non-UTC offering. 


SOLVED! for myself anyway and the issues I was having with Survey 123 Connect and Survey 123.  This issue has been plaguing us for years, creating unnecessary confusion, downtime and duplication of work for thousands of records. A fix to the issue was sought since there do not seem to be any  plans to move AGOL away from UTC. In our case the issue was made more problematic by the fact we use daylight savings time which has differences north (QLD - AEST) and south (NSW - AEDT) as well as east and west and time changes twice yearly by one hour.  Recovery of correct datetime data was made possible since we captured photos at the start of the survey. Using the photos downloaded from AGOL or extracted from the FGDB the original datetime in the EXIF data to at least get a verification of day and good approximation of time assuming photos were needed at the start of the survey. Data may be further adjusted using SQL to subtract minutes from the photo datetime to better reflect the actual start time of the survey. 

The way I resolved the issue of AGOL changing the displayed 'correct' datetime of the device (tablet, phone etc) to UTC was to STOP using the 'start', 'end' and 'datetime' field types in S123 Connect. Added to that I stopped using the 'bind::esri:fieldtype' of 'esriFieldTypeDate'. In this way AGOL does not try and manipulate data of type datetime. 

It is still possible to use 'start' and 'end' field types with this solution but it will cast a letter 'T' to prefix the time based on ISO 8601 ([YYYY-MM-DDThh:mm:ss[.nnnnnnn] eg 2021-12-13T20:39:19). There is no issue with having the 'T' but it may mean extra work if you need to remove it using SQL. The most common form is 'YYYY-MM-DD hh:mm:ss[.nnnnnnn]' for an MSSQL date format like datetime2(7).  The benefit of using 'start' as a datetime field at the start of the survey is to show you a clear day, date and time of your survey as the device 'controls' show datetime fields different to text fields.  The 'start' data will be modified by AGOL and would deleted from the final production dataset. The fix to be described would be the actual datetime value used which can be triggered to populate itself using a simple 'relevant' expression in S123 Connect like 'string-length(${SurveyStartTimeUTC})>0' assuming your 'start' field name is 'SurveyStartTimeUTC'.  

The solution I implemented to resolve the issue of UTC time manipulation was to simply hide the fact datetime data was being stored. ,  eg Instead of getting this value supplied by AGOL ('13/12/2021 9:40:46 AM') we get the ACTUAL local time and required format ('2021-12-13 20:39:19.994').

The steps used are as follows;

1. Whichever field represents the survey start time change the 'datetime' field type to 'type' 'text'. 
2. Check to ensure the 'bind::esri:fieldtype' of 'esriFieldTypeDate' to esriFieldTypeString of set length to say 25.
3. Add the 'calculation' format-date(now(),'%Y-%m-%d %H:%M:%S.%3') using qualifiers in the format-date function to yield '2021-12-13 20:39:19.994'.  You can set qualifiers and layout how you need it eg order, dashes, colons or add leading zeros. (Dates and Time in Survey123 - Esri Community)
4. Once complete Publish the survey to test, Use the survey, Send the data to AGOL, Download the data from AGOL as FGDB to get full field names (not truncated field names as resupplied in shapefiles).

In AGOL be aware that if you export as CSV or XLSX it may cause further datetime issues for your correctly formatted data. If the CSV or XLSX is opened in O365 Excel 2016 it may reformat datetime data the way it sees fit. Excel may replace your colon or dash  format with say forward slants, and may even convert dates or times to decimal values. Reversal of this process can be problematic and time consuming to say the least, especially if you have to keep defining the format. This can be a nightmare to fix as excel is very persistent as it knows best.

Using this following simple solution your dates and times will stay as the dates and times that were displayed on your device at the time of capture.  This is critical as you data makes its way from the paddock to the cloud and back to your machine,  exactly the same as what you captured and formatted. As a bonus date data may be stored in text and if it is formatted correctly the field type can be simply changed in your database system (eg MSSQL) to match its datetime data and format conventions.