nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

DateTime now() outputting previous date

DustyJordan

Hello,

I have a survey set up with a DateTime field that uses the now() function to automatically capture the current date and time while collecting records. I've used this function in the past with no issues, however on this new form I am noticing an issue where the saved date ends up being the previous day to which the survey was actually conducted.

Upon closer inspection I was noticing all the dates in question seemed to be around the 23:00-24:00 hour mark. I then noticed that the date/times that did not seem affected are still displaying very early in the morning (0:01-4:00). I'm guessing that something is occurring where it is subtracting 12 hours from the default "now()" date and time.

I'm assuming this perhaps has something to do with a 12-hr vs 24-hr formatting issue, although I have done no calculations or formatting changes on this DateTime field.

Hoping someone may have some insight into what is happening here and how I can correct it. Xlsx file attached in case that helps.

Thank you!

-Dusty

BTS Bait Tube Servicing.xlsx

Find more posts tagged with

Accepted answers

LongDinh

Hi @DustyJordan ,

Since you are using AGOL, the timezone setting is set when you created your hosted feature service. It can be re-configured by updating the service definition. I found this article which will assist in the process. By default, your feature service would have been published in UTC+0.

In ArcGIS Pro, when you add the service to a map, you can check the layer's time zone setting in Layer Properties > Time tab.

I would assume the S123 app will look at your device's timezone setting and adjust accordingly from the feature service's timezone setting. When you view it in ArcGIS Pro, the data comes in as UTC+0 and will need to be either mentally calculated or rehandled by a pop-up. On ArcGIS Online, the date is converted according to your computer's time. For working with dates in ArcGIS Online, see this article.

If you want to check the exact date value being uploaded by S123, you might be able to:

Get the gdb on your device's S123 AppData folder which should contain a copy of any unsynced (drafted) surveys. This only works for surveys with is offline capability enabled), or
Try writing the date as an integer - datetime values are stored as epoch timestamps in milliseconds.

All comments

LongDinh

Hi @DustyJordan ,

Try reviewing your DB feature class settings. If you have access to it via an ArcGIS Enterprise then you should review how your feature class is set up. If you are using AGOL, then it most likely set in UTC+0. Else, review how service JSON parameters.

Excel is notorious for mishandling datetimes (and data in general). When you write to your feature service, it will write it to an epoch timestamp relative to the feature class' time setting. It is best to open your export in a text format like csv and open it in a text editor.

Users uploading 12-14 hours prior to the service time may be correct as the data is stored in UTC+0 but your application is viewing it as UTC+xHours.

Unfortunately, it is difficult to hit a default setting on a data source/service without having to alter/rebuild/migrate existing data structures. The field usually does not contain the time setting. It is at the data source. Your applications should handle the time difference as describe by your service (which is usually derived from the data source).

Have you enabled change tracking on your feature service? This may reveal how your times are written in your database.

DustyJordan

Hi LongDinh,

Sorry to come back to you with this issue! I seem to still be running into the problem with the DateTime field in my survey displaying a modified result in the DB and in exported Excel tables. I also have at least one user who's records are throwing out all kinds of crazy dates now, some a year in the past, some 3 to 14 years in the future! I have a feeling that might be a issue on his local device (personal smartphone). However, many other users are still uploading data with dates 12-14hrs prior to the actual service time.

Really starting to wrack my brain trying to figure these issues out. Although I feel scrapping this whole survey and starting over would be nice, it's not really an option seeing as we've already accumulated a significant amount of data in this feature service. Is there by chance some way I could hit the default button on all these timezone settings? Or perhaps a way to delete fields and recreate new ones with new/default timezone settings?

Thanks again for any guidance you may be able to offer!

DustyJordan

Hi LongDinh,

Sorry for the delay in getting back to you, but I was eventually able to resolve my time issues. The blog post you shared above was very helpful in navigating this process.

I adjusted my timezone settings in the service definition and in ArcGIS Pro, but was still seeing issues in the downloaded data. I eventually realized I needed to update my ArcGIS Pro to the latest version and this then automatically adjusted all my time values to the proper timezone.

I also decided to take the DateTime field and calculate/format it out into separate Date and Time fields as a string, which I believe will circumvent this issue in the future. This is what I have done on all my other surveys in the past and is likely why I have never run into this issue before. Not sure why I didn't just do that from the beginning for this survey as well.

Thanks again for your time and effort in helping me sort this out!

-Dusty

LongDinh

Hi @DustyJordan ,

In ArcGIS Pro, when you add the service to a map, you can check the layer's time zone setting in Layer Properties > Time tab.

If you want to check the exact date value being uploaded by S123, you might be able to:

Get the gdb on your device's S123 AppData folder which should contain a copy of any unsynced (drafted) surveys. This only works for surveys with is offline capability enabled), or
Try writing the date as an integer - datetime values are stored as epoch timestamps in milliseconds.

DustyJordan

I feel like a dumb, but I can't seem to find most of these settings you've listed. I've gone through the S123 app settings, the feature service layer settings on my AGOL portal, but don't see time or timezone settings anywhere. I'm not sure where the database settings would be. I've pulled the feature layer into ArcGIS Pro and can't seem to edit any timezone settings there either (I may be missing where the proper settings are).

I've noticed when using the S123 app in the field today the time field seemed correct, so I imagine this is happening somewhere between the collection and upload process? It's odd because I've created several surveys now and never messed with any time or timezone settings, and never had any issues until now.

Could you provide any more guidance on where I might find some of these settings in order to troubleshoot this better?

Thanks for your time, it's appreciated!

LongDinh

@BradMayo usually the source data and service are set to UTC+0 and the application will localise the time based on the user's device.

BradMayo

@LongDinh UTC+0 for all of those? I don't think I can adjust the device to work with UTC + 0 or is that separate from the application(s) on my phone?

LongDinh

Hi @DustyJordan ,

This will depend on a number of things which handle your datetime object's timezone which may be double handling your view of the datetime value. Things to consider are:

The database timezone settings,
The device's timezone setting,
The feature service layer's timezone settings
The feature service layer's field timezone settings,
The S123 timezone settings, and
The viewing application's timezone setting.

Any number of these can handle alter the datetime view. To check where it may have been handled again, it is best to go from the source (database) to service then to application and determine if there was a shift in the datetime view/timezone.

It's often recommended to work in UTC+0 for these reasons.

Hope this helps!

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.