Daylight Savings affecting Survey Date

[DarraghOSullivan]

Hi,

We collect the completion date of a survey using a Date field and today(). This is expected to give a timestamp of 12pm as far as I understand. However, some of our records are showing as 11am. The only thing I can assume, looking at the patterns, is that this reacts to Daylight Savings time in Ireland. Is this correct, and is there any way to avoid this? I need this field to be consistent to integrate with Power Automate.

Thanks

[Anonymous User]

Hi @DarraghOSullivan,

Are you using the field app or web app to submit the data? If the field app what version? If the web app, what version was it published with, and do you have version locking on?

What timezone (locale) are the devices being used set to? 

Where do the see the time difference, when you export the data to excel, or do you see the same times in AGO/Enterprise in the Data view of the feature layer?

Regards,

Phil.

[DarraghOSullivan]

Hi @Anonymous User ,

Thanks for your reply. 

The data is submitted using the field app. The data has been collected over the last 18 months or so, meaning different versions, but Require Update is turned on, so always the latest one.

Devices (iPads) are set to Dublin time.

I had only been checking the exports, which are automated daily using ArcPy and assumed it was like that in the Feature Service. But I just checked and they are all at 12pm in the Data view of the AGOL feature service!

So could it be something in the Python or in Excel, which we export to?

Thanks again,

Darragh

[Anonymous User · Accepted solution]

Hi @DarraghOSullivan,

Yes, that makes sense, in AGO/Enterprise, we store dates fields as UTC with a date/time and timezone. When the data is displayed in an app or web map or data view, it converts that UTC time to your local time equivalent. Therefore if the surveys are collected during daylight savings or not, the time will reflect the same when you look at it at any given time in the app or in AGO data view. However when you export the data and display it else, you need to take this into account, and ensure the time zone difference are applied.

Regards,

Phil.

[DarraghOSullivan]

Hi @Anonymous User ,

Thanks again, yes that makes sense and is a relief that the issue is not at 'source'. In the meantime, I'd applied a workaround (i.e. much longer Excel formulae!) to make it work at that end, so maybe I'll stick with that!

All the best,

Darragh