Timezone updates need to be fixed
creativedeletion.com
creativedeletion.com
I got fed up with this and migrated all the data so it's saved in local time with the timezone information in a separate column. If an admin creates an event for 4pm, we save 4pm with the event location's timezone. Since an event only takes place at one specific location, it makes no sense to have the data in UTC in the database. We can convert to UTC if we want but it's not really useful. The thinking is that if a client is shopping for a class in a different timezone, why would we convert the class's time to the client's timezone? It makes no sense. It's always in local time. This has helped so much.
For example, the bypass valve on the boiler must be opened in 30 hours. You want that as UTC instead of wall time as you don't want a DST change to add an extra hour to that as you'd get a pile of scrap instead of an intact boiler.
* Store datetime values in UTC. Else you get inconsistent values, which has unpredictable consequences.
* Detect user's expected timezone using one of : a) user preference setting, b) the region the app is supposed to be running for, c) IP geolocation. Choice depends on the app requirements. Don't default to any timezone unless considered 100% safe.
* Present DB values in the UI using said detected timezone.
* UI-wise, slways display timezone information for datetime values. At the very least in a tooltip.
The key difference is here:
> The thinking is that if a client is shopping for a class in a different timezone, why would we convert the class's time to the client's timezone? It makes no sense.
Roughly speaking, basically there are two kind of apps:
- apps where datetime values need to be localized ("this message was sent at 18:00")
- apps where datetime values need to reflect a fixed timezone ("we will meet in Madrid, at 18:00 local time")
For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones.
Storing in local and then converting from one timezone to another timezone on demand has far more edge cases and gotchas. Plus it too isn't immune from rule changes, if you store in local time (e.g. 10 am) but DST rules changes, from an outside observer's perspective (someone in any other timezone) the meeting's time has now changed.
So even just using that edge case you're talking about exchange one downside (local time changes) to another downside (remote time changes).
Saving as UTC doesn't really solve the issue (although it seems like it does).
The issue that the previous posters (Khao, laut) didn't make explicit is that we have 2 concepts of datetimes:
1) scientific datetime (which UTC is unambiguous, except for obscure things such as leap seconds)
2) socially-constructed datetime (which "local" time + TZ resolves most (but not all) of the ambiguities)
Scientific(UTC) datetime works great for past events like server logs, and some types of future events such as celestial events. For example, the upcoming solar eclipse in August 21 2017. Regardless of what future DST rules are decreed by the government, the moon is going to move in front of the sun at a 16:48:33 UTC time.
Socially-constructed future datetime such as appointments don't work the same way. For example, we presume that a Super Bowl on the east coast in the year 2025 will have a kick off of 6:30pm but we can't encode that as UTC unambigously because we don't know today what DST rules will be in effect 10 years from now. In 2016, we don't know whether to encode it as 22:30UTC or 23:30UTC.
That said, if the planning horizon is short (such as sending out alerts for an upcoming conference call to participants spanning timezones), one can encode it as UTC internally and then decode it to local wall-clock time. It may be simpler that way with less bugs.
Intervals should be stored in UTC. If you're supposed to drop the control rods in a reactor in 24 hours you store the time it's supposed to happen in UTC. DST transitions and rule changes would mess this up if stored in local time.
Timestamps for logs and files should also always be UTC.
If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00 UTC. If my timezone changes due to a new law UTC is not wrong; the event is still going to happen at 13:00 UTC! If the event was previously stored as a local time and not UTC the EVENT is wrong! You solve this by handling the TZ conversion elsewhere and making sure it always has the latest rules.
Always store in UTC. Your argument makes no sense.
If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
YOU just rescheduled the event.
Works the same with dates and not just times. If you store each of those events individually and the politicians move the DST switch date (or an error was corrected in the TZ database) then some of your event times will now be an hour off.
UTC is still the correct way to store it if you want it to be timezone-aware.
If every event a specific application needs to be at local time regardless of what the timezone is, stop storing any reference to a timezone.
UTC is the correct was to store timestamps (things that happened) and intervals (things that need to happen x seconds/minutes/hours from now).
For future events at a specific geographical location you need to store it as local time + timezone. Many databases have a time+timezone type.
And yet, you keep emphasizing "rescheduling" in relation to UTC instead of local time. We already know that DST changes changes the underlying absolute time in UTC. And that's the very reason why you cannot store a future datetime as UTC!
Here's a trick question to put your advice about storing future appointments as UTC to the test:
You want to save a datetime for the New York Times Square midnight countdown to ring in the New Year on December 31, 2018 @ 11:59:45pm. As far as the user is concerned, his/her brain thinks in terms of local wall clock time and therefore, that would be 2018-12-31 23:59:45 ET. (Notice it is "ET" and not "EST" or "EDT")
Do you think you can save that user-specified datetime to the database as UTC?
Do you think it's 2019-01-01 04:59:45UTC ? (Wrong answer.)
Do you think it's 2019-01-01 03:59:45UTC ? (Wrong answer.)
If you don't see why both of those UTC choices are incorrect, please study the previous posts.
To recap the problems with UTC:
-- you don't know in 2016 what future UTC timestamp to write to the database. The user doesn't know either. Nobody knows. It depends on what the government does in the next 3 years.
-- UTC implies scientific precision and writing it to the database for future datetimes will incorrectly advertise that you have the clairvoyance about future rules. You don't.
-- UTC is correct abstraction level for past events (server logs, audit logs) and future non-human generated scientific datetimes such as moon phases and solar eclipses. UTC is the incorrect abstraction level for human generated appointments' datetimes.
Attempting to save a socially-constructed future "wall-clock" datetime as UTC is throwing away information the user gave you. Stop advising people to do that.
I think I see the confusion here. If you went to a group of people and said the movie you were all going to was rescheduled from 11pm UTC to 10pm UTC because of DST you'd get a bunch of "Huh?" and "What local time was it rescheduled to?" You'd answer it was rescheduled from 6pm to 6pm local time. You'd get a bunch of laughs at your "geek humour" while they secretly thought you were nuts. :)
Social events like meetings, movies, etc. are not considered rescheduled when DST starts/stops or the TZ rules get changed.
If you stored the event as UTC you'd have to alter your database when DST starts/stops or the TZ rules changed (is your system going to compare the old and new rules automatically now?).
What does that mean to reschedule? Run a SQL batch job on the database to shift the UTC times by 1 hour?!? Which rows? All of them? Or the rows for a particular TZ? (Better make sure that SQL WHERE clause is error free.) You're just recreating the ambiguity problem but from a different direction.
The issue you keep missing is the UTC is ambiguous when attempting to store the scheduling intentions of the user. If the user wants to store a future socially-constructed datetime, storing it purely as UTC will throw away information.
The users will rightfully expect their time to stay 14:00 Santiago time if they enter 14:00 Santiago time.
By saving the series' time as 6pm EST in the database, we can save all the individual occurences without having to do any check for DST changes in the middle of the series.
The users are simply interested in knowing when their yoga class is, the class is at 6pm, that's it. Before or after DST change, it's still 6pm.
Edit : Even if we had locations that were running 24/7, I don't think there would be any issue. An event that starts at 10pm and ends at 4am after a DST change? Any good datetime library will tell you that the event runs for either 7 or 5 hours, when calculating difference between those 2 datetimes when knowing the proper timezone. We're using C# and the standard .Net datetime library is one of the best I've ever worked with.
We've had a lot of problems with a platform that stores recurring events as UTC date + time delta (eg. 1 week). What the users want is an event that happens every week on a certain weekday and time, in their timezone - they don't care if that falls on various times in UTC throughout the year.
Of course, that's specific for recurring events/schedules.
But the data itself is not new software. It is just data.
Functionality should not change because of new data.
DST, for example. What if a state stops observing DST? Arizona observed DST in 1967, but hasn't since then. A couple other states are considering abolishing it, too. You can easily imagine software doing something dumb when it can't find its DST entry in tzdata.
NTP deliberately makes only very tiny changes gradually when adjusting clock time backwards. Automatic updates also normally abort if the time difference would be more than 1000s (~16m). This is all fairly well-documented.
It seems that in some countries, time zones just change randomly. Maybe people should just stop doing that. Countries only move a couple of centuries a year. And there is no reason to mess with DST other than to get rid of it all together.
I don't disagree, but how do we get there from here? Our "betters" have even had the gall to make this type of change in the recent past, and even to claim "energy efficiency" as a motivation. This is is--how do I put this?--a wronger than wrong version of not even wrong.
Doesn't have to accurate, just impressive. And then maybe next time, circulate the report just before the decision has to be taken.
> Countries only move a couple of centuries a year.
That's some pretty advanced time travel tech.
> If you make a system that uses timezone data, think ahead. The timezone data is updated as often as 10 times a year or more. In case you have an embedded system that is not connected to the internet all the time, how can that processes be put in place to make sure it is updated?
A decade or so ago, nothing updated, and when DST changed, you had to reset every clock in the house. There was maybe a day or two of confusion where you couldn't remember if you changed a clock or not, but easily dealt with.
Now, in my house anyway, almost everything automatically switches (with the notable exception of my stove and microwave clocks, but heck, those still don't even have battery backup for when the power flickers). This is probably even more annoying, because now it's not a matter of remembering if I switched it (in the last day or so) or not, it's remembering if the device itself switches automatically or not. I can't remember stuff like that, so basically for a day or two after DST I don't trust any clocks at all.
Worse is when the devices still have the old (pre-2007) DST rules built-in. We're lucky in NA that the rules don't change that much, but when they do, they do break all these old devices. The most annoying item I had (notice past tense) was a beside clock that auto-set itself I believe based on the WWV [1] signal, and had a setting for time-zone and would of course do DST shifts automatically. Pretty neat, when I first got it, but after 2007, I had to manually change the timezone on this "auto-setting clock" 4 times a year.
That's odd, because the WWV signal contains extra flag bits that authoritatively tell you when DST is starting and ending. I guess the manufacturers decided to ignore that data and reimplement the time change themselves.
https://en.wikipedia.org/wiki/WWV_(radio_station)#Daylight_s...
Of course, IIRC it also only had 4 timezone settings, so I guess if you lived in Hawaii, Alaska, the Atlantic time zone, or Newfoundland, you were out of luck. And if you lived in Arizona or Saskatchewan or any other place that didn't observe DST, you were also out of luck. (Well, you could at least manually adjust the time, which I think turned off the auto-DST stuff).
If you use the Elixir library mentioned in the article, it will already have been updated. If you use Mac OS X Yosemite it will probably never be updated.
TZ are politics and politic is very bad at making stuff engineerable. Politics are inconsistent, unstable and lack of rigor in propagating the information to the coders.
The TZ definitions are handled by clerks that writes an XML files manually that are embedded in your libs and that no one cares to update.
TZ are not versioned. So if you want to know what was the local time 12years ago in any place of the world : good luck.
But international exchange are bound to delays workhours and SLA requiring delays to be measurable ... With arbitrary changes (EST shit).
Timezones are broken by design and all our applications too.
The only way to solve the problem is to forbid politics to come anywhere near science, history and standardization of measurement. Corporation don't do any better. I abide by International System (metric) and the idea that there should be a monotonic non disrupted absolute time whose origin IS NOT the birth of Christ but since when we are able to have continuous "rigorous" measurement of time.
Which is exactly the opposite of what people calls for.
The begining of the year should be the aphelia (3~4 jan) and not some religious bat shit conventions. Noon should be when the sun is at its top. And 13 month of 28 days (+intercalar days) would make our lives easier.
Time as a political and religious construct is shit.
Not 100% sure, but from what I know, Rails gets timezone handling right. Specifically, it leverages the https://github.com/tzinfo/tzinfo gem. So, correct me if I wrong, by performing `bundle update` you're all good?
Less than a week's notice of the change, and it was between Christmas and New Year. Ouch.
Use gps coord. And utc to know if you have a lunch or breakfast, dinner meeting
Time zones have no precision so why use them?
As long as we're regular users, we need to work around these realities.