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).
Related
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 am trying to design an application that allows Support personnel to show system tray alerts between a certain time window in future on all user machines.
So we have clients in multiple time-zones checking in to a central server looking for any new alerts to be displayed.
The central DB has a table that stores the alert details with their start/end time and a webservice that responds to the clients by checking this table.
The challenge is that the client as well as the future trigger time on the server can be in any user-specified timezone.
Based on a few threads that I read here, the best practice is to store the start/end time in UTC in the database and convert it to the client's timezone when a request comes in.
That would mean converting all start/end times to client's timezone every few mins. I am worried this would be a major performance issue on the central server. Handling Daylight Savings times is also another point to consider.
Is there a smarter way to handle this? Any best practices to handle such scenarios would be really help.
Assuming you are using SQL, then you'd want to use DateTimeOffset as the data type. This type is capable of storing & manipulating both timezone and DST information.
Please see the accepted answer in this thread for the canonical answer to this class of issues: DateTime vs DateTimeOffset
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 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.
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.