GlobalID and time zone

[AliNazari]

I am downloading data from my Survey123 page into a csv file. The date time field is not accurate in the table because the users locations are not collected correctly. I need to find out what is the time zone of each data point so I can convert my datetime field to the local time zone where all my users (and our organization) are. and the only identifier I suspect can be helpful is "GlobalID".

Is there a way to get the time zone from the GlobalID?

[RobertBorchert]

By default database times is going to be GMT.  for my organization it works out ok as our work hours on a given day fall between GMT 0000 and 2400. So the time is off 5 or 6 hours but the date is correct. 

I did have one group of people in an application years ago that wanted to export the photos taken with collector and name them by location name and date and time.  So I created a formula in MS Access to convert the time to -5 or -6 depending on the time of  year. I had to update it the next year because the time change was on a different date. However the project ended and I only had to change that once. 

The end result of the iff formula was to subtract .25 or 0.208333 depending on what time of the year it was. 

I applied it to all 5 parts of the parts of the dated

Your situation appears that you have people collecting in multiple time zones.  You will then want to use a search by location using a time zone polygon and designate which time zone they are in and act accordingly 

[jcarlson · Accepted solution]

The GlobalID is just a unique identifier, and has nothing to do with any of the other attributes, including the time or location.

The date/time values collected are stored as timestamps in UTC, unless the time zone for the service was otherwise specified. I'd suggest reading this excellent post about how S123 works with date/time values. You may be able to configure your survey to save a hidden field representing the UTC offset of the user's device or a separate timestamp, though that only helps you moving forward.

To calculate the "local time" of prior submissions, you'll probably need to add a new field and calculate its values. You could do this easily enough by spatially intersecting your points with the World Time Zones layer and using the Zone field.

EDIT: I should add, if all your points fall into the same time zone, you could apply the offset in Excel once the data is exported. The rest of the AGOL universe will adjust for the local offset of the device accessing the data, so permanently adjusting the values in the field will cause your times to display incorrectly elsewhere. So again, I'd still use a separate field for this.