DateTime.Now: No, no...

Laurent Bugnion on May 28, 2019

Recently my colleague and friend Donovan Brown was in Switzerland for customer visits and for the DotNet Day conference in Zurich. I took the occas... [Read Full]
markdown guide
 

We can change default timezone in App Service by adding a new setting under Application Settings called WEBSITE_TIME_ZONE.
Acceptable values for this setting can be any of the acceptable values defined in the Windows Registry under the key HKLM\Software\Microsoft\Windows Nt\CurrentVersion\Time Zones.

 

That's correct. Like I mentioned in another comment thread, I was merely using App Service as an example to illustrate that the server is running on UTC, but your comment is very correct and appreciated.

 

Thank you for this interesting thing. But I think it could be a workaround, but not as right "pattern".

 

I am not quite sure what you think is a workaround. The mere fact I want people to be aware of is that Azure servers run in UTC 😊

 

SPAs made thinking about this problem a lot easier: localisation belongs in the client that runs in the browser. So in the backend (and its APIs) everything is UTC.

But I can relate to your point that it was hard when we were rendering web pages on the server. I actually have a Ruby-on-Rails project in which I had worked on the time-zone-abstracted layer, as well as on the time-zone-respecting layer. UTC belonged in the controllers and database for sure, local time in the views, but my models were a mix of both.

 

That is truth! I use momentjs to forget about time manipulation at all.

 

Yes to be clear I didn't intend to solve any time related issue here, merely wanted to make people aware that Azure servers run in UTC.

 

Nice post, particularly on the interesting bit that Azure defaults to UTC.
I would, however, be careful with stating to just use UtcNow and make conversions, as people tend to think of it as a silver bullet, as this post by Jon Skeet points out.

 

very good decision by the Azure architects, if you ask me :)
they force you to think about the topic before/so that it does not become a problem later :)

 
 

I would also switch or build all new applications using DateTimeOffset.UtcNow 🙂 in case I would deploy it somewhere else I'd be able to track timezone.

 

Yes there are variations of course. The .net code here was more there to illustrate the point but you are right of course.

 
code of conduct - report abuse