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.
* 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.
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.
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.
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.
Less than a week's notice of the change, and it was between Christmas and New Year. Ouch.
> 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).
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.
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?
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.
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.