Handle timezones in a datetime field in an archived database

[PaulFarrow1]

If the datetime is stored in UTC and you are in a different timezone to the server - how should you handle the timezone issue.  When syncing the archived geodatabase to and from the server should that process handle the timezone manipulation?  Or how do people handle this?  I just don't seem to be able to make it work correctly in all scenarios.

Thanks

Paul

[JenniferNery]

The dates are read and stored in UTC.

If you want dates displayed in local time, you can use `DateTimeOffset.ToLocalTime()` to convert the date attribute (in UTC)

((DateTimeOffset)f.Attributes["created_date"]).ToLocalTime()‍

And if you are querying for features and have local time as input, convert this first to UTC before setting query parameters.

var ld = DateTimeOffset.Parse("11/20/2018 12:47:03 PM -08:00");
p.WhereClause =$"created_date = '{ld.ToUniversalTime()}'";‍‍

Was there a specific sync scenario where you don't find this to be working as expected?

[PaulFarrow1]

Hey Jennifer

Thanks for replying.  I think what I am after is there is nothing specific to syncing that would change a datetime field from local to server timezone datetime?

Its basically read UTC to local then save local to UTC in your own code?

Paul

[JenniferNery]

Yes, properties of DateTimeOffset type are converted by runtime API to UTC before it's stored or sync'd to server.

For example, if you have the following code... this local time will be converted to UTC.

f.Attributes["submitted"] = DateTimeOffset.Now;
await t.UpdateFeatureAsync(f);‍‍‍‍

If editor-tracking was enabled, the `created_date` and `last_edited_date`, auto-generated fields, are also stored in UTC. So if your app wants to display these date time attributes in local time, you'd have to call ToLocalTime(). Other date fields related to sync - like when you create geodatabase, the `replicaName` includes creation time is also in UTC or when you sync geodatabase, the `submissionTime`, `lastUpdateTime` are also in UTC.

My query sample above with where clause on a date field may be the only other time app is responsible for converting local input to UTC because now we're dealing with text and not a date time object. If you should use QueryParameters.TimeExtent, since Start/End times are of DateTimeOffset type, they are expected to be converted by runtime API to UTC before it's sent for query to server.

If you have a specific case in mind that is not addressed here, I can check it out.

Thanks.

[PaulFarrow1]

Thank you.  Nothing specific at this point, it was just confirmation around the syncing process of the datetime fields.

Paul