Some time ago I put together a time based library that could be used for working out relative times within a year for someone. I noted at the time, that it did the one hour shift in both directions for daylight savings. It just occurred to me that Congress changed the daylight savings time rules. I don't recall seeing any information about updates to resolve the change in algorithms. Does anyone have any information on this topic?
Most Unix-like systems use the Olson tz database for their timezone information:
http://www.twinsun.com/tz/tz-link.htm
The changes to the US timezone rules were implemented in version 2005l of the tz database.
For Visual Studio 2005 and earlier, Microsoft has released updated versions of the C runtime libraries. More information can be found here.
What platform are you working on?
Since Congress doesn't set the rules for the whole world :) there has been a mechanism for flexibly specifying the rules on Unix/Linux for a long time
See, for example, http://www.manpagez.com/man/8/zic/ for the format of the files. Your particular system may need an updated definition for the new rules (if the distribution hasn't dealt with it already)
For Windows, MS build in some rules and release updates when things change.
For MacOs, I have no idea, but I imagine it inherits the Unix way of doing things.
But in all these cases, no change to the C library should be needed
On a more general note, the C runtime does use internal data files to map from the internal time representation to the user's locale. These mappings are updated regularly by the respective vendors to match current legislation.
Since internal clocks should be set to UTC, daylight saving time is just a matter of changing timezone. For example, on my locale, on October 26 my Mac switched from CEST ( central european summer time ) to 'normal' CET ( central european time ). My clock's display changed, but not the computer's time.
http://www.timeanddate.com/library/abbreviations/timezones/eu/cest.html
Indeed this means you absolutely have to keep your datetime variables either in UTC or in a native format that takes the timezone into account. That's why just recording datetime as a "YYYYMMDDHHMMSS" string, is a bug waiting to happen.
Related
Daylight savings came into effect at 1AM Sunday March 25th 2018 and will again come into effect on 1AM Sunday March 29th in 2019 within my timezone.
I'm aware there is an is_currently_dst flag in sys.time_zone_info however I'm looking to identify the specific point of change its self.
Can this be identified dynamically within SQL server going forward?
Short answer: no. Long answer: this is OS specific and at present SQL Server offers no abstraction over the DST rules beyond the very simple sys.time_zone_info.
You can grab the time zone info and use a specialized client library to get the adjustment rules. .NET has TimeZoneInfo, and you could use a CLR function to reflect this info back into SQL Server. There's also third-party support (disclaimer: no experience).
Alternatively, 2016 offers AT TIME ZONE to do certain calculations, which may or may not be enough for your purposes. It will not allow you to identify the previous change in a straightforward way, but it does allow you to determine if DST was in effect for any particular point (by comparing time zone offsets with a known point).
I am developing a client-server mobile app (e-shopping), and can't decide what time source to use when displaying estimated package arrival time to the client. I am leaning towards retrieving a time value generated on the server and converting it to the device time zone to work around cases when time on the client's device is set incorrectly. However, the time zone on the device may also be set differently. Is there any generally accepted good practice regarding that ?
Timestamps such as the ones you describe should be stored in terms of UTC (Coordinated Universal Time) on your server
Generate UTC-based values on your server - which are independent of the server's time zone setting.
Transmit those UTC-based timestamp to your client in a machine-readable format that preserves the context that the timestamp is in UTC. Preferably, ISO-8601 timestamps such as 2018-05-09T18:00Z (the Z indicates UTC).
On the client device, convert that timestamp to the desired time zone. In the case of mobile devices, choosing the device's time zone is reasonable. It would be quite unreasonable IMHO to concern yourself with whether or not the client's time zone was set correctly. The time zone is a user-controlled preference. If it's set to some other time zone, then that is the time zone that should be used. You should not try to overcompensate.
Format the timestamp as a string that is human-readable, using the preferred localization settings of the client device, and show that to the user.
Much more on this topic is already written. Start here.
Store and persist the estimated time with your servertime and recalculate it to the devicetime in the app itself. So your data remains consistent in the storage/DB but every user has his time zone displayed.
I have a silverlight application which users will be running in various time zones.
These applications load their data from the server upon start up, then cache it in IsolatedStorage.
When I make changes to the data on the server, I want to be able to change the "last updated time" so that all silverlight clients download the newest data the next time they check this date.
However, I'm a bit confused as to how to handle the time zone issue since a if the server is in New York and the update time is set to 2010-01-01 17:00:00 and a client in Seattle checks compares it to its local time of 2010-01-01 14:00:00 it won't update and will continue to provide old data for three more hours.
My solution is to always post the update time in UTC time, not with the time on the server, then make the Silverlight app check with DateTime.UtcNow.
Is this as easy as it sounds or are their issues with this, e.g. that timezones are not set correctly on computers and hence the SilverlightApp does not report the correct UTC time. Can anyone say from experience how likely it is that using DateTime.UtcNow like this for cache refreshing will work in all cases?
If DateTime.UtcNow is not reliable, I will just use an incremented "DataVersion" integer but there are other scenarios in which getting time zone sychronization down would make it useful to thoroughly understand how to solve this in silverlight apps.
DateTime.UtcNow is as reliable as the clock on the client system. So the question is entirely independent of Silverlight or .NET, the question is how much do you trust the system clock on the client machines?
You need to weigh the risk that a user of a machine may have incorrectly set the time on their machine because they have not set the time zone correctly. This risk is entirely human in nature.
Using an incrementing version number only has one downside, you need to first retrieve the current value before you can set a new one. If that isn't a problem then go with that and eliminate the FUD you might have around time zones.
I have a database, which is a part of a Library Information system. It keeps track of the books borrowed by customers, keeping the due dates and automating the notification of accountability of customers, if a customer has returned a book beyond their due date.
Now, I am using MySQL for the DBMS. What I know is that MySQL's time is dependent on the system time. When checking if a borrowed book has already passed its due date, I would compare the current System time with the due date value associated to the borrowed book. Yeah, the database server will actually be running on a PC running winXP.
My problem is, when the system time gets changed, integrity of the data and checking of accountability gets compromised. Is there a way to work around this? Is there a sort of 'independent time' that I could use? Thanks a lot!
NOTE: Yeah, I'm afraid the application does not have a connection to the Internet.
I think you're trying to program around a problem your application shouldn't worry about. Your app gets time from the computer, you need to be able to rely upon that for accuracy. If the time gets changed, then the time was wrong, so what does that mean for old data? How long was it wrong? It's really not something you can solve programmatically.
A better solution is to make sure the time isn't wrong. Use windows time to sync against a time server to ensure accuracy.
If your PC is running within a Windows domain service, you could also choose to have your computer clock constantly synchronize its time with your domain server using the Windows Time Service.
If your PC has internet access, it can actually set its time against US National Institute of Standards Technology time service. Instructions and overview of how to use it can be found at the NIST Internet Time website.
I would configure an authoritative time server in windows XP. Here is a step by step process.
(I am new to Python and Google App Engine, please forgive me if my questions seem basic).
I'm having a helluva time trying to manage multiple user timezones in my Google App Engine application.
Here are my constraints:
If a user enters the time on an input, it will be local time (including DST, when appropriate).
If a user does not enter the time, the system must enter it for them in their local time (including DST, when appropriate).
When the date and time are displayed to the user, it must be in their local time (including DST, when appropriate)
I understand that time will be internally stored as UTC with a tzinfo object and that the App Engine will store the Models with UTC time.
I previously thought I had this all worked out by asking the user to specify their time zone in their preferences. Then, I would simply load their preferences and add that tzinfo to any datetime objects in reference to that user.
However, our recent daylight saving time broke it. It turns out that I had not correctly implemented the dst() in my tzinfo objects. As I understand it, I must determine if DST is currently on, and if so, return the correct offset for the tzinfo.
The problem is, I have no idea how to determine if the timezone's daylight time is current or not. Am I missing something obvious?
If you can, I'd recommend having a look at the python-dateutil package, which has tz objects pre-built for all timezones, including DST offset information. I don't think there's a way to "just know" if DST is on or not without supporting data... it's date driven for most timezones (or, at least, timezones that support DST), and the dates vary according to local custom, politics, and all manner of things.
http://labix.org/python-dateutil
I see some problems here.
If the user enters the time, it enters it in local timezone, but how do you know which one is it? Europe/Vilnius or Europe/Madrid? Or maybe Australia/Melbourne? If you don't know the timezone, the date/time becomes "naive".
The only timezone database which is considered appropriate and accurate (considering the state of constant flux) is Olson timezone db, available for Python as pytz package. It allows for easy converting dates/times between timezones: first you take date/time and timezone from user, localize date/time in user's timezone then take it as utc, ready to save to your database. Display is other way around: get date/time from database, localize in utc, then display as user timezone.
And the last thing: there is no such thing as automatic DST transformation. In the case of ambiguous dates/times you have to know in advance in which timezone the time is entered. That's our human reality.