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.<p>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.
<p><pre><code> But the data itself is not new software. It is just data.
Functionality should not change because of new data.
</code></pre>
Well, <i>ideally</i>, yes. But software breaks all the time when you give it data the programmer didn't expect, which happens especially often with time.<p>DST, for example. What if a state <i>stops</i> 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 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.
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.<p>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.
One of the biggest problems with tzdata is only mentioned in passing in the article:<p>> 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?<p>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.<p>Now, in my house anyway, <i>almost</i> 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>I</i> switched it (in the last day or so) or not, it's remembering if the <i>device itself switches automatically</i> 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.<p>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 <i>that</i> 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.<p>[1] <a href="https://en.wikipedia.org/wiki/WWV_(radio_station)" rel="nofollow">https://en.wikipedia.org/wiki/WWV_(radio_station)</a>
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.
2016a has been released: <a href="https://www.iana.org/time-zones" rel="nofollow">https://www.iana.org/time-zones</a><p>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.
Timezone problems (cf The Problem with Time & Timezones - Computerphile on youtube or postgres doc on why not to use TZ) are not solvable.<p>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.<p>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.<p>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.<p>But international exchange are bound to delays workhours and SLA requiring delays to be measurable ... With arbitrary changes (EST shit).<p>Timezones are broken by design and all our applications too.<p>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.<p>Which is exactly the opposite of what people calls for.<p>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.<p>Time as a political and religious construct is shit.
The IETF has been working on distribution issues and, amongst other documents from the tzdist working group, produced this: <a href="https://datatracker.ietf.org/doc/draft-ietf-tzdist-service" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-tzdist-service</a>
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.
Are up-to-date Rails applications exposed to this issue?<p>Not 100% sure, but from what I know, Rails gets timezone handling right. Specifically, it leverages the <a href="https://github.com/tzinfo/tzinfo" rel="nofollow">https://github.com/tzinfo/tzinfo</a> gem. So, correct me if I wrong, by performing `bundle update` you're all good?
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.
All use utc and stop the daylight saving and timezone...<p>Use gps coord. And utc to know if you have a lunch or breakfast, dinner meeting<p>Time zones have no precision so why use them?