We are based in the UK and have a series of web services deployed to Azure. One of these automatically refreshes every 5 minutes and displays a 'Last refreshed at hh:mm:ss' message.
It appears that this is not taking into account daylight saving time as the time displayed is one hour behind local time. We suspect it is using UTC. We have tried setting
<globalization uiCulture="en" culture="en-GB"/>
in the web.config and programatically with no success.
Is there an easier solution to display the correct local time than having to determine the DST offset and applying it at every instance of 'DateTime.Now()?'
Thanks in advance for any help.
In the Azure Portal under Application Settings add a environmental variable with the name WEBSITE_TIME_ZONE with the value W. Europe Standard Time.
For other values, see: https://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx
#viperguynaz is correct, all of Azure runs on UTC. If you're running in Azure, then you should keep it running in UTC and not try to circumvent it as some things don't behave very nicely then. Instead, as a software developer, you should add the ability into your application to honor time zones and to handle data saved as and services running on UTC. Never use DateTime.Now but instead always use DateTime.UtcNow.
For more info on this, see this question.
Yes - Azure runs on UTC time. Read DateTime.ToLocalTime Method and TimeZoneInfo.ConvertTime Method for how to get the local time with time zone known.
We have a similar UK specific situation and we simply set the timezone using the timezone utility tzutil within a single line "elevated simple" startup task:
tzutil /s "GMT Standard Time"
We haven't seen any issues with this and the timestamps always match our expectations. This seems simpler than ensuring that every DateTime interaction in code is made local time / timezone aware.
I believe that this utility is only included in images of Windows Server 2008 R2 and beyond.
Related
I have written a blocking user system in node.js. I'm using nodejs, mongodb as data base and mongoose, expressjs and Reactjs.
I have successfully written the blocking logic and unblocking logic. I used mongoose $currentdate feature which fetches the currentdate but uses the current date of the local machine.
I simply said if expiryDate === currentdate, user should be unblocked.
I also tried to use Javascript to get the current date and it uses the local machine date and time.
Why I feel this isn't right is because the user's date and time maybe wrong. I tried this out by setting a wrong date on my local machine and the Javascript date system was setting a wrong date for me as well. This will surely make a mess of the unblocking logic.
If I write my logic using this, it can be dangerous since I do not have control over the user's local machine date and time settings.
Is there really a better way to get this done? I will be deploying the application to be hosted online in Amazon ec2 or haroku. This is part of my learning process actually. Wanted to know how this really work.
How do applications that use billing methods track my days? For instance, if I start a subscription today and the subscription lasts for 7 days, no matter the current state of my local machine date and time, the subscription will surely expire on the 7th day.
How can I achieve this? I would like the expiry logic to be independent of the user's local machine date and time.
Any npm package that can do this or best way to go about this?
If you don't want to depend on the system date, you have to use NTP (Network Time Protocol)
To use NTP in your node script, you can use an NTP module, one of these for example:
https://www.npmjs.com/package/ntp-time
https://www.npmjs.com/package/ntp-time-sync
https://www.npmjs.com/package/ntp-client
I have few NTP servers that I use with multiple platforms (Ubuntu, RHEL etc). I have many machines pointing to these servers and time is synced up as expected. I need to create a custom time-zone on the NTP server such that I am able to manipulate the DST settings for this timezone? I.e. need to have the ability to perform Spring/Fall DST on any specific date on as needed basis.
Is this even possible?
Interesting question - NTP has no concept of time zones [1] nor DST [2], that is down to the underlying OS/Subsystem.
NTP simply serves up the time & date in UTC.
Not sure what your usage case is - but you would need to either look at doing what you want at OS level, or simply running everything in sync to your own version of UTC. (As in you could have a closed time domain, serve the time from 1 server and manipulate it as you wish slow it down or speed it up etc.)
Agreed with every answer here. NTP server itself has no concept of time-zones. As pointed above, I was able to get the latest tzdata from their FTP repo. Manually edited the 'northamerica' file in VI to change the DST rules. Saved and compiled using zic. This link is also very useful.
I want to be able to change the date and time on my vm to dates in the past. Every time I change it, it automatically changes back because of this setting. Unfortunately I cannot change it because it is disabled. I am logged in as an admin on the vm. Any ideas?
Try this:
Hyper-V Time Synchronization Service, startup set to "Manual"
Windows Time Service, startup set to "Manual"
BUT based on this article, it 's not recommended so maybe the safest way is to add time offset in you program
I have an IIS 7.0 server configured to rollover logs daily. However it appears that the logs rollover at 10am each day. How/where do I configure this so that they roll over at 1am?
The logs use UTC and roll-over UTC day bounaries, this is by-design.
You can switch to Local Time by checking the "[ ] Use local time for file naming and rollover" box on the Logging screen in IIS Manager.
Besides local vs UTC, you cannot specify a custom timezone or arbitrary point in time for the rollover.
I'm from Russia, and 1,5 days ago (at 2AM, Oct 26) our timezone (ok, offset of our timezone) has changed - from UTC+4 became UTC+3. Please, don't ask why now - it's out ******* goverment :( But it changed.
My home Win 8.1 machine updated automatically.
But only one (!) of my Azure resources is updated. One Cloud Service updated, while one more Cloud Service and 4 websites are not updated - they are still at UTC+4 offset.
I know, all Azure servers are in UTC in settings, but I speak about TimeZoneInfo data on them.
I'm requesting
var tz = TimeZoneInfo.FindSystemTimeZoneById("Russian Standard Time")
and this timezone is still
(UTC+04:00) Moscow, St. Petersburg, Volgograd
while my home machine is in
(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)
AFAIK, this depends on system updates on server - new timezone data must arrive prior to any time changes can actually happen. But why servers are not updated?
My one CloudService as working properly now, showing correct timezone info (can't show it), so at least one server is updated correctly, while others are not.
I made small website to test this: http://timezonetestrussia.azurewebsites.net/ (source: https://github.com/justdmitry/AzureTimeZoneTest )
It shows TimeZoneInfo.Local info and from "Russian Standard Time". At this moment, it shows this in Azure:
Id
Russian Standard Time
DisplayName
(UTC+04:00) Moscow, St. Petersburg, Volgograd
StandardName
Russian Standard Time
DaylightName
Russian Daylight Time
BaseUtcOffset
04:00:00
SupportsDaylightSavingTime
True
DateTimeOffset.UtcNow
10/27/2014 2:37:58 PM +00:00
TimeZoneInfo.ConvertTime(DateTimeOffset.UtcNow, tz)
10/27/2014 6:37:58 PM +04:00
While on my local machine it shows:
Id
Russian Standard Time
DisplayName
(UTC+03:00) Moscow, St. Petersburg, Volgograd (RTZ 2)
StandardName
Russia TZ 2 Standard Time
DaylightName
Russia TZ 2 Daylight Time
BaseUtcOffset
03:00:00
SupportsDaylightSavingTime
True
DateTimeOffset.UtcNow
27.10.2014 14:33:50 +00:00
TimeZoneInfo.ConvertTime(DateTimeOffset.UtcNow, tz)
27.10.2014 17:33:50 +03:00
The most likely reason is that different services run on different Guest OS "versions". You likely have automatic Guest OS updates enabled (osVersion="*") which means that Azure is free to update the Guest OS. Different Guest OS versions withing the same family include different sets of updates. Things like rules for timezone adjustments are typically distributed using updates too.
Look at guest OS updates feed http://sxp.microsoft.com/feeds/3.0/msdntn/WindowsAzureOSUpdates - they cannot release a new OS to all users for months already. The process was started multiple times, they updates some of the users and then stopped the process. It's likely that your "proper working" service got the OS updated and the other services have not got the OS updated. You can perhaps verify this using Management API http://msdn.microsoft.com/en-us/library/azure/ee460804.aspx Get Deployment call.
I am researching if Azure can be updated with the new time zones, but I don't believe it is directly possible. Or rather, since you aren't given access to the OS that your Azure Web Site runs on, you wouldn't be able to apply the updates yourself. You will likely have to wait until the next major Azure Guest OS update. I will update this post if I learn otherwise.
If you can rework your program, you might instead consider using Noda Time. It has its own time zone data, which comes from the IANA time zone database. Be sure to use an updated .NZD file, as the Russian changes are covered in IANA 2014f or greater.