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.
Related
I have a requirement where I want to run a test case in PDT time. So I tried to change date and time of my windows machine(a VM) but it gets automatically reverted back to current date and time . I want a help regarding that.
I have time server sync. checkbox off as well as windows time service and hypervisor time service is also off on the VM.
Please post your thoughts
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.
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.
User downloads an App (which assume is a game) from server. I need to enforce time constraint on how long a user can run an Application on a system.
eg. Starting from the time of installation, user can use the Application till only 5 days.
My problem is, if I depend on system time/day etc for implementing this logic, user might change the system time and overcome the logic.
Platform: Linux/C++
P.S.: I have to assume a case in which user decides to not connect to internet at all after he downloaded the Application. Since I don't have network access so can't rely on server based storage about Application's installation date/time etc.
Can someone give a clue how this kind of behavior is implemented in Applications which give a trial period of their usage?
Edit:
I am adding the Algo which I am thinking:
At installation time :
At the time of installation store the current system date.
Store this info in an encrypted form into a file DRM.txt
On App startup :
Open the file and decrypt the installation date.
Get the current date from system.
Match if the application is allowed to be executed according to the number of days that have passed since user installed it.
If allowed, start the App else give error msg and return.
Problem:
Let at the time of installation system date is 19/12/2012 and user is allowed to use the App only for 4 days that is till 22/12//2012. Thus, 19/12/2012 is stored into DRM.txt.
After 4 days user changes the system date back to 20/12/2012, then my logic to check will allow this Application to run.
Hope this clarifies what I am trying to say.
This can be achieved through encryption, for example storing a date into an encrypted file, note that this won't prevent reverse engineering, etc, etc, etc
Save and check the time when start and stop the APP.
If the current time is much shorter than the saved time, then you can think it is cheating.