If you enable time on the layer before publishing, it will apply the UTC offset to your local time.
One more comment from me, since I am struggling with this again as I write this. I have time enabled the data in the MXD I am using for my service to resolve the UTC issue. Unfortunately my data has more than one date/time field that I need visible to the user in a pop-up (AGOL webmap). Only the date/time field that is specified in the Time settings for each layer appears as it does in the data, the other date/time fields are displayed incorrectly in UTC. This is obviously not good 🙂
Please address this issue ASAP, Brady Hoak' comment above would be ideal if its the easiest fix. Allow the user in the web map to decide how date/time is handled for each layer and possibly at the feature layer level if the service is added to AGOL as an item.
I have found that all of the dates within services or shape files are one day earlier than in the layers once I upload them to AGOL. What I am mapping is fire department responses to fires, so there is an alarm time and date, an arrival time and date, a controlled time and date and a last unit cleared time and date. The solution involving setting the time zone in Desktop works perfectly on one field but doesn't correct the other three. Unfortunately we have to have all of the dates because and alarm could come in just before midnight so it would be one date for the alarm and another for arrival. The same goes for the controlled and cleared fields. The work around I came up with was to add extra fields and then use the calculation tool to add a day.This idea would make my life a lot easier.
You can specify the timezone for your data when publishing from Pro. You can find the setting in the Share As Web Layer dialog under the configuration tab > configure parameters:
It would be great if this functionality could be used for Survey123 created layers. Currently if we export to CSV for further reporting or analysis (which often include analysing response times) our dates are out. This could end up being a deal breaker while we consider if we use Survey123.
Is there anything you can do in ArcMap to replicate giving the entire dataset a time zone? I know you can use the Time tab in layer properties to change it for one or two date fields, but I have some datasets that require three or more date fields and this causes problems in ArcGIS Online.
For example, three separate date fields for Incident Start Date, Incident End Date, and Incident Reported Date.
Please add portal also. I am trying to create a map and dashboard of our fire incidents in our portal and it also converts the date fields (of which there are many). ArcGIS Pro is not an option for us currently because you have to publish to a federated portal/server which is a separate issue with its own problems.
I agree. We really need the ability to 'tell' the webmap that it should not automatically try to convert time to (or from) UTC. If I create a label showing DateTime on the layer as part of a dynamic map service, this label is apparently passed without time conversion to the webmap as I want it to do. Viewing a popup for the same feature in the webmap shows another DateTime-value because of the UTC conversion, in some cases it even results in another date. Image here showing an offset of 2 hours around midnight.
It's very hard to explain the meaning of this to an end user.
Hi Katie,
When I attempt this in ArcGIS Pro the final hosted feature still uses, shows, and displays all its timestamps in UTC time.
Might this be a bug? I am trying to host the feature on a company Portal, not AGOL directly.
Thanks!
ESRI absolutely should give an option to show dates in local time on ArcGIS Online. Frankly, I can't believe this feature isn't offered. For us working in municipal government (in other words, very local), the correct date and time is crucial for our viewer apps. As other people have noted in this thread, the default UTC time can change the actual date as it was entered. Our apps are used daily by inspectors and planners where the date is of upmost importance, who do not want to hear that they need to add a day to every date given in the popup windows. Setting a timezone in one or two fields is not sufficient at all for us, and actually would only add to confusion to have a couple fields in local time, while the rest remain in UTC (we frequently have datasets with multiple date columns). Manually creating a text field or another date field using Field Calculator could work i suppose, but that seems like a pretty absurd workaround to what should be a simple issue.
Is there a way to do this through code? Using the helpful script here only puts time/date fields in UTC. I need to specify UTC London/Dublin and adjust for daylight savings.
Or worse, the year we moved Daylight Saving Time 3 weeks in the Spring and Fall, to save power.
ENERGY POLICY ACT OF 2005
And this great video of "Time" issues
The Problem with Time & Timezones - Computerphile
Useful link for students to an esri help document about time zone math including an AGOL tool.
ESRI's Time zones—what time is it anyway?
Map URL: http://esriurl.com/fourgeoinquiry2
The new functionality that was added to allow you to pick the time zone works great when first adding the data. However, when you go to use the Update Data >> Overwrite Entire Layer option it doesn't ask for the timezone again and resets it to UTC.
Vote up for this (really old) idea! The setting for time zone should be in the AGOL feature service properties somewhere. You should not have to re-publish the service to change it.
It would be extremely useful to be able to publish data that contains time/date fields and not have the UTC conversion (or any conversion) automatically applied. We have users that collect field data on projects across many time zones, and when they view the data, it is quite frustrating and confusing for them to always have to think about what time zone they were in at the time of collection, and what time zone they are in right now. When writing reports, it's more helpful for them to be able to look at the data and remember that they collected that point at 9am on that specific date in the local time of the field site - not seeing it converted to the timezone of the office they are sitting in while viewing the data which might be telling them they collected the data at 5am instead.
I concur with the OP and probably with a lot of the posts I didn't read. I frequently need for the time that is displayed in ArcGIS Online and ArcGIS Enterprise to be the same as the time value in the source data... for business purposes. Enabling time on the layer and in the service adds other complexities that don't get me toward a solution consistently. Thumbing up this one.
Oh, wait... I see that a lot of customers have wanted this for a long time. I guess I should just forget it and move on.
This is very critical to the Municipality of Anchorage. I concur and it needs to apply to ArcGIS Enterprise portal as well. The end result of the application changing the date time fields is if you are accessing the data from a different location, you are getting an incorrect answer. The editor needs to be able to pick a date and have the option to be confident that the date entered by the editor will be the one that is always displayed no matter where you are accessing the information.
This is also a problem with AGOL maps in Collector. I publish the maps from Pro in local time, but when I make edits in Collector, the edit time shows up in the SDE feature class as UTC.
Hello,
Another option is to use Arcade expressions to change to UTC. I have done it today ( ) and works fine!
ToUTC($feature["FECHA_FICHERO"])
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"])))
regards!
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.
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...
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.
It's been more than 10 years since this issue was posted for the first time and it is still not solved, even though it seems to be a major problem for many of us! My team and I only work with data in one time zone (UTC +1) and all our users are also only located in this same time zone. While pop-ups and the time slider widget respect our local time zone, the filter doesn't, which leads to a big mess which is very hard to explain to our users who are not experts in GIS, databases or time zones.
We everytime hear from ESRI "this works as designed" but how can it be designed so inconsistently? Pop-ups, time slider and filter need to be aligned at least! How am I supposed to explain to a user that he gets two different results depending on whether he filters the data with the time slider or a calendar filter? We are located in Austria and work with local data only. We will never have a use case where we would like time to be converted to UTC. And since we are only 1-2 hours off of UTC, it makes things even worse, because users often don't realize that a conversion even happened.
We use dashboards now whenever possible (which is not always the case), because they magically can deal with local time zones correctly. So why can ESRI not design it like that in the other apps/map viewer?
@MattKennedy are there any new developments in this area?
Sign in to post, follow content, and more. New here? Register for free.
.png)
