(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.
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 am using SQL Server 2008. The server is in india. I want to store the users login and logout time. I can easily do that in SQL Server.
Now we have clients/admins from different countries who will check those login/logout time. They want these times in their respective time zone.
One more scenario is my clients travel from one country to another country, so the log time should be automatically updated as per the timezone.
So my understanding is I have to store the timezone info along with datetime for clients. So that I can use TimeZoneInfo::ConvertTime method to convert to different time zones.
I can give my clients an option to save their timezone while registration.
But my doubt is if my client changes his country do they need to change their timezone manually or is there any way i can automatically detect timezone. Is it feasible to check for the system timezone?
Or anyway storing timestamp can help me?
Use datetimeoffset. My company has operations all over Europe, a few Asian countries, and North America. Code your application so that it passes along the timezone setting of the current computer to the database. When a user travels, Windows can update the timezone information as it detects the geographical location of the user. I never had to worry about DST that way (imagine the fun dealing with daylight savings time in 2 continents).
Since the timezone info is stored, I can convert it to any timezone I want. Or the application reading the data can do that, using the local computer timezone.
I have a newsfeed program, and I've got many client applications (about 70) across a few timezones that generate events, for example when a secretary schedules a meeting it adds to the list on the server. This list is served to every client that wants to view it. Currently each record has the following metadata:
random unique ID
local timestamp (YYYY:MM:DD:H:M:S:ms)
How do I sort these events on the server, such that they appear in the correct order they were submitted in? Currently they get mixed up since local timing doesn't match. I don't have any UTC timestamps (can I calculate these locally?), so I'm wondering if I can make-do with the information I got... or should I be getting more information from each client? I noticed even clients in the same timezone get events mixed up because their system time is not synchronized (is it possible to know the exact global time, or synchronize the system time with a server on Windows?)
I'm not asking for code, I just need a pointer in the right direction.
When storing temporal values it is essential to always use UTC. Anything else and you're screwed. You really should also store the related timezone along with the UTC.
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.