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.
But the data itself is not new software. It is just data.
Functionality should not change because of new data.
Well, ideally, yes. But software breaks all the time when you give it data the programmer didn't expect, which happens especially often with time.
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.
I don't think it is a good idea to shield bad software at the expensive of having incorrect out-of-date data. Developers should be aware that tzdata changes all the time, and create software that can deal with it.
I got programs connecting to servers in different countries. It was such a pain to keep the time in sync with all the different time zones and daylight savings. So i ended up using utc everywhere.
i even set the clock on the wall and my wrist watch to utc. That way I'm also in sync with my programs. People who visit tell me my clocks are wrong. But i know its the the rest of the world that is wrong.
Yes. Unix time is utc based. I used manual syncing to ntp server once in a while. Automatic syncing scares me a bit. What happens when it adjust backwards in time. Programs that are running and use elapsed time logic might get very confused. Elapsed time since an event happened might become negative.
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.
Interesting. Still any backward adjustment however small seems potentially dangerous. I googled a bit and it seems many ntp services can slow down the time until its in sync instead of adjusting it backwards. That seems safer.
Generally it isn't a backward adjustment but simply a slowing down of the clock until the 'real time' catches up. On the other side, you speed up a clock to catch up to the real time rather than catching up all at once.
How about a way to encode future timezone changes? If a country votes for a timezone change it doesn't become law tomorrow. Usually they schedule it for a date in a few months. If a week after the vote tzdata knew this then there would be no rush.
Tzdata can encode future changes, but that's only helpful when politicians change the rules on advance and notice is given to the team that manages the data. Many jurisdictions don't appear to consider the impacts of changes and make changes with little notice.
Looking at this from a 'Unix in Europe' perspective, the timezone data has rules. So as long as the rules don't change you don't need updates. And due to the need to coordinate with many countries, timezone rules in the EU essentially don't change.
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.
One option is to get one of those big name companies to write a report on how much that change cost to the economy due equipment that had to be written off, downtime, etc.
Doesn't have to accurate, just impressive. And then maybe next time, circulate the report just before the decision has to be taken.
One of the biggest problems with tzdata is only mentioned in passing in the article:
> 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.
> 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.
Wow, that actually makes me very frustrated, because it means not only did they ignore that flag (not read the documentation?), they actually did more work to implement a tzdata database and check against the current date to change it.
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).
As someone who just spent some time figuring out why Australians were getting errors on the site I work for, I fully support standardizing automatic updates. Since the site is running a two year old version of PHP, it looks like I either have to update the PHP version to the latest (just to be safe) or add the timezonedb PECL package. This seems to be a ton of work just to get something that should be updated automatically.
Where I work we deal a lot with events (yoga gyms, community sports centers, etc.) and the old code was saving EVERYTHING in UTC. Every 6 months we'd have some bug report coming in saying that some event was now one hour later or earlier on the website, or in some report, or in an admin edit screen.
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.
Nice article. For your rule of thumb section there is a third case. For a future event that must happen x number of seconds/minutes/hours/days into the future you want to store it as UTC and not wall time.
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.
Good point. For that that situation you would want to use something like UTC (or TAI). It is the duration from the starting point that we care about, not the future date.
* 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.
In our case, the admins who create/manage those events have to specify the event location, so we fetch the timezone for that location and if there's any mismatch, they can change the timezone manually. Since we migrated all the data, we have not received a single bug report for an issue that was caused by DST or from converting UTC times to local timezones.
I retract my opinion - the approach is clearly correct for that business domain.
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")
In our app, everything that's a timestamp (invoices, payments, registering to an event, sending messages, create/update timestamps, etc..) is stored in UTC. Having both depending on the use case is really the best for us.
One edge case doesn't disprove a rule, and timezone/DST rules changing is definitely an edge case.
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).
>For internationalisation storing in UTC is still the gold standard, since it remains consistent with itself across time and DST zones.
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.
I disagree. Storing as UTC is the only sane way. It will never get corrupted. Calculating the timezone difference for the user is not that hard and won't result in a database full of mistakes you have to scramble to fix.
Not for events like shows, movies, work hours, etc. An event starts and stops at a specific local time. If the DST rules change then the UTC version will be wrong but the one stored in local time + TZ will be correct.
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.
UTC is an anchor. It does not change, it is never wrong. Your application or environment may live under different rules because of location but that problem can be solved by the timezone-aware application.
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 the user expects 8:00 local time then it should stay 8:00 local time. That is at least how people would want their applications to work 99% of the time. If someone enters 8:00 and then the software suddenly changes it to something else, that is confusing.
If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
Wrong. Let's say an event is scheduled for 6pm daily in Toronto (EST -0500). You store it as 11pm UTC. Now eventually we switch to EDT -0400 due to DST. Now your system will say the event is at 7pm local time.
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.
We don't agree. It was not rescheduled in reality. Your system would have said it was rescheduled to 7pm Toronto time while in reality the event would still be 6pm Tronto time. The people using your site/app/whatever would be an hour late.
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.
I would go as far to say that the timezone stored should be a named, geographically-based timezone (e.g., America/New York or Canada/Eastern) as opposed to a timezone offset. (If you store the timezone as EDT or EST, you have still encoded -0400 or -0500.)
I find it hard to believe that you can't see how people are obviously using the word "rescheduling" in relation to local wall-clock time. The wall-clock time as the reference point is how everyday people commonly use "reschedule". When we flip DST on and off, nobody says "schools and banks got opening times got rescheduled."
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.
> The event was literally moved to a different time UTC. I'm glad we agreed that it was rescheduled.
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?).
>Congratulations you literally just rescheduled the event.
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.
Did you read the article? If a user wants to save a local time and you then convert it to UTC and save that instead, then it can in some cases be impossible to later find out what the entered local time was.
The users will rightfully expect their time to stay 14:00 Santiago time if they enter 14:00 Santiago time.
How do you handle DST? Do any of these locations run 24/7? I've found DST to be a compelling case for storing everything in UTC. Times get converted to the correct local time when displayed in the UI.
We simply ignore DST. For example let's take a recurring event that happens every Wednesday at 6pm for 10 weeks. In the middle of those 10 weeks, this timezone enters DST.
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.
Funny; DST is exactly what made me doubt the rule of storing everything in UTC.
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.
My HTC One still uses years old timezone information for its clock widget. I fixed the main clock by setting timezone to a different timezone that I'm actually in, but the clock widget is still off by one hour. It's extremely infuriating. Apparently you can't update timezone information in Android unless you have root, which is completely idiotic.
Are up-to-date Rails applications exposed to this issue?
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?
AFAIK you can use the tzinfo-data gem. Someone needs to manually update it though. So far it looks like it is still on the previous 2015g and not on 2016a that just got released: https://github.com/tzinfo/tzinfo-data
Timezone problems (cf The Problem with Time & Timezones - Computerphile on youtube or postgres doc on why not to use TZ) are not solvable.
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.
60 comments
[ 3.1 ms ] story [ 114 ms ] threadIf 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.
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.
https://www.eecis.udel.edu/~mills/ntp/html/index.html
Less than a week's notice of the change, and it was between Christmas and New Year. Ouch.
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.
[1] https://en.wikipedia.org/wiki/WWV_(radio_station)
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).
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.
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.
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?
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.