Track Time Zones or UTC-Offset of Entered DateTime

1042
3
10-21-2019 10:25 AM
ErikHerberg
New Contributor III

Is there any way to extract the time zone abbreviation or the UTC-Offset of an entered date/time in a survey? I know about using pulldata("@property", 'utcoffset') to capture the UTC offset when the form is submitted, but that's not what I'm hunting for. 

I use repeats in my forms, and each has their own date/time, some of which are in the past. A hypothetical example: We are filling out a form on March 12, 2019 (this is Central Daylight Time, UTC -5). We have one repeat from that day March 12, 2019 11:00 and another in the past, like February 23, 2019 11:00 (Central Standard Time, UTC -6), from before the switch from Standard Time to Daylight Time (on March 10, 2019). Using pulldata("@property", 'utcoffset') will just populate every repeat with "-5", since the form is submitted in UTC -5. How do I extract the UTC offset of the entered Date/Time, not the submission date/Time? So the March 12 repeat would save the timezone or offset as -5 and the February 23 repeat would show -6? I know this information is saved somewhere, because when I export the feature layer to excel, the times are accurate in UTC 0: March 12, 2019 11:00 (a dateTime that falls in UTC -5) becomes 16:00 and February 23, 2019 11:00 (a Date/Time that falls in UTC -6) becomes 17:00. I just can't figure out how to access it. Or is it an export setting?

Thanks,

-Erik

0 Kudos
3 Replies
JamesTedrick
Esri Esteemed Contributor

Hi Erik,

As you note, the pulldata("@property", 'utcoffset') is used to capture the current UTC offset of the device.  To address what you are looking for, you would need to have the repeat capture the UTC offset at the time it was created.

Unfortunately, there isn't a way to capture the UTC offset of a date after the fact of submission as Survey123 doesn't have the logic to determine anything about that past capture.  Remember that all dates are stored in ArcGIS Online as UTC timestamps; when loading information, it doesn't know what timezone a date/time is collected in.  From a human perspective, we may want to infer that the time recorded was in the time zone of the point collected at that location on a given date, but there is not any logic forcing it (you can, for example, collect a survey whose point is in Tokyo while standing in Washington, DC).

0 Kudos
ErikHerberg
New Contributor III

Thank you James.

I think I understand, but just to confirm, I'll ask in a slight different way, specifically about daylight savings shifts. First, the facts, as far as I understand:

  • The times are stored in ArcGIS online as UTC 0.
  • The device settings determine the UTC offset to apply when submitting
  • So, when I enter a survey and the first repeat has local dateTime of July 1st, 2019 at 10:00 (Central Daylight Time, UTC -5) and the second repeat has a local dateTime of January 1st 2019 at 09:00 (Central Standard Time, UTC -6), the times for both of these are then saved as 15:00 in UTC 0. My device knows to use -5 for dateTimes that fall during Daylight time and -6 for dates that fall during Standard.

So to confirm, there is not a way to extract and save the UTC offset that my device is automatically applying?

FYI to anyone else that may stumble across this thread and have a similar question - I ended up following the Solution reported on this thread to manually detect if an entered dateTime falls in either Daylight or Standard time for my local area: Calculating if date is summer time . This could have been applied outside of Survey123 after exporting data out of ArcGIS online as well, but for our work flow it was easier to implement directly in Survey123. 

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Erik,

The pulldata("@property", 'utcoffset') will record the UTC offset of the device at the time the form/repeat is created. As you note, a function can be made to determine if a particular date is in daylight savings or not, but it's difficult to generalize given that daylight savings varies from country to country (and even state to state).

0 Kudos