Arcade on Calculate Field does not respect the Time Zone of Windows

3764
9
Jump to solution
05-12-2021 12:37 PM
VHolubec
Esri Regular Contributor

Hello,

I have a FGDB to which I add a date Field. I tried to calculate the current day and time, but I was not able to get the correct results.

The function Now() get me the current day, but the time in UTC instead of UTC+2

The function Today() give me yesterday date and time 22:00. 

Do I something wrong, or these two functions needs to be added with something?

My workflow is also in attached video.

Thank you.

Vladimir

Vladimir
0 Kudos
3 Solutions

Accepted Solutions
DanPatterson
MVP Esteemed Contributor

Just test here  and now...

python works with datetime.datetime.now()

arcade doesn't  with Now()


... sort of retired...

View solution in original post

XanderBakker
Esri Esteemed Contributor

Hi @VHolubec ,

In a web map when calculating the local time using "ToLocal(Now())" would work and therefore I am a bit surprised why it still returns the UTC time when you do this. I just tested this and that's what happend.  @Anonymous User any idea why?

There is a tool that allows you to convert time between time zones (https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/convert-timezone.htm ) but to be honest the time zone selection is not very user friendly (for instance I couldn't find the Colombian time zone). 

Another way is using the DateAdd() function to manually change the time zone. I used this in my case:

DateAdd($feature.DateTime, 7, 'hours')

 

Now, there is something you need to keep in mind. If you live in a country with daylight savings, losing the reference to UTC might create errors in interpretations later on. There should be an option in the configuration that defines how you want to see the data times (in UTC or convert to local time zone). There are some options when you enable time on your layer, but if you don't want to do that, it should be possible to see the date and time as the user wants. @Anonymous User what are your ideas on this?

View solution in original post

by Anonymous User
Not applicable

Hi @XanderBakker & @VHolubec - here is my take on the situation:

By itself, Now() should return the local time. In the ArcGIS Pro pop-up profile and ArcGIS Online calculate field, it returns the expected local time for me. When calculating a field with Now() in Pro, I am also reproducing the behavior where the value is returned in UTC. Since Now() should always return the local time based on the system's time, I think this could be a bug with calculating fields in Pro. 

A couple things to keep in mind though: if you are calculating this value on an ArcGIS Online hosted feature layer, you want it to be in UTC time. The reason for this is that all date values in a hosted feature layer are in UTC and the browser converts them to local time when viewing. Pro does not apply the same conversion when viewing date fields. So if you calculate into local time instead of UTC in Pro, then your field will show the incorrect time in web apps. 

For a local dataset, I don't see any reasons for not using the DateAdd function shown above. Just make sure that when publishing as a web layer, you specify the time zone your date field is in. In the publishing process, your field will be stored in UTC with an offset applied, but will display in your local time zone in apps.

For example, I'm in Pacific Time (right now UTC-7). If I have my date field locally and the time is 2:30pm for a feature, then I publish to ArcGIS Online and specify my time zone, in the Online database that date field will now be 9:30 p.m., stored in UTC. However since my browser is UTC-7, when I go to view that date field in a map/app it will subtract 7 hours and show me the right value of 2:30 p.m. 

I hope this helps -- this is a great blog on time that you've probably read too.

Thanks,

-Peter

View solution in original post

9 Replies
DanPatterson
MVP Esteemed Contributor

Just test here  and now...

python works with datetime.datetime.now()

arcade doesn't  with Now()


... sort of retired...
VHolubec
Esri Regular Contributor

@DanPatterson , sorry I forgot to add, yes the Python function works great.

 

Vladimir
0 Kudos
DanPatterson
MVP Esteemed Contributor

problem solved! 😉

 


... sort of retired...
Jelle_Stu_PR
Occasional Contributor II

What happens if you add the ToLocal function?

VHolubec
Esri Regular Contributor

@Jelle_Stu_PR, still the same. I will dig deeper.

Vladimir
0 Kudos
XanderBakker
Esri Esteemed Contributor

Hi @VHolubec ,

In a web map when calculating the local time using "ToLocal(Now())" would work and therefore I am a bit surprised why it still returns the UTC time when you do this. I just tested this and that's what happend.  @Anonymous User any idea why?

There is a tool that allows you to convert time between time zones (https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/convert-timezone.htm ) but to be honest the time zone selection is not very user friendly (for instance I couldn't find the Colombian time zone). 

Another way is using the DateAdd() function to manually change the time zone. I used this in my case:

DateAdd($feature.DateTime, 7, 'hours')

 

Now, there is something you need to keep in mind. If you live in a country with daylight savings, losing the reference to UTC might create errors in interpretations later on. There should be an option in the configuration that defines how you want to see the data times (in UTC or convert to local time zone). There are some options when you enable time on your layer, but if you don't want to do that, it should be possible to see the date and time as the user wants. @Anonymous User what are your ideas on this?

by Anonymous User
Not applicable

Hi @XanderBakker & @VHolubec - here is my take on the situation:

By itself, Now() should return the local time. In the ArcGIS Pro pop-up profile and ArcGIS Online calculate field, it returns the expected local time for me. When calculating a field with Now() in Pro, I am also reproducing the behavior where the value is returned in UTC. Since Now() should always return the local time based on the system's time, I think this could be a bug with calculating fields in Pro. 

A couple things to keep in mind though: if you are calculating this value on an ArcGIS Online hosted feature layer, you want it to be in UTC time. The reason for this is that all date values in a hosted feature layer are in UTC and the browser converts them to local time when viewing. Pro does not apply the same conversion when viewing date fields. So if you calculate into local time instead of UTC in Pro, then your field will show the incorrect time in web apps. 

For a local dataset, I don't see any reasons for not using the DateAdd function shown above. Just make sure that when publishing as a web layer, you specify the time zone your date field is in. In the publishing process, your field will be stored in UTC with an offset applied, but will display in your local time zone in apps.

For example, I'm in Pacific Time (right now UTC-7). If I have my date field locally and the time is 2:30pm for a feature, then I publish to ArcGIS Online and specify my time zone, in the Online database that date field will now be 9:30 p.m., stored in UTC. However since my browser is UTC-7, when I go to view that date field in a map/app it will subtract 7 hours and show me the right value of 2:30 p.m. 

I hope this helps -- this is a great blog on time that you've probably read too.

Thanks,

-Peter

XanderBakker
Esri Esteemed Contributor

Thanks @Anonymous User for jumping in.

Will you get back when you know if the behaviour in Pro is indeed a bug?

It would be nice to have a setting in ArcGIS Pro where the user can decide in what time zone he/she wants to see a date-time. Do you know if this is on the roadmap?

VHolubec
Esri Regular Contributor

Hi @Anonymous User , Hi @XanderBakker ,

thank you both, I send it to our tech support! The commnad: DateAdd(Now(), 2, 'hours'), works also fine!

Vladimir

Vladimir