The creator of DST gets the first slap. Then the timezones asshole.
I'm planning to do a presentation at work on how to deal with dates/times/timezones/conversion/etc in the next few weeks some time. I figure it would be a good topic to cover. I'm going to start my talk by saying "first, imagine there is no such thing as timezones or DST." And then build on that.
Before I read this article, I also thought it would be a great idea to get rid of timezones entirely and just use UTC for everything. To quote from the link, (please forgive me for being lazy and not formatting it correctly)
Abolishing time zones brings many benefits, I hope. It also:
causes the question "What time is it there?" to be useless/unanswerable
necessitates significant changes to the way in which normal people talk about time
convolutes timetables, where present
means "days" (of the week) are no longer the same as "days"
complicates both secular and religious law
is a staggering inconvenience for a minimum of five billion people
makes it near-impossible to reason about time in other parts of the world
does not mean everybody gets up at the same time, goes to work at the same time, or goes to bed at the same time
is not simpler.
As long as humans live in more than one part of the world, solar time is always going to be subjective. Abolishing time zones only exacerbates this problem.
I used to think this way, then it was pointed out to me that, without timezones, we'd be in a situation where Saturday starts mid-workday in some places.
It could have been worse. The romans had the day divided into 24 hours, like we do, but the hours varied in length so that from sunrise to sunset, you would always have 12 hours.
Imagine if that was the agreed upon time system, and we had to program that into computers.
Timezones are fine to program around.
DST is a bit of a pickle to plan around, but can be done just fine by a computer program.
Historical dates; considering leap years, skipped leap years, and times when leap years weren't a thing or when humanity just decided we skip a bunch of years; are the bane of all that is good.
Timezones are kind of a necessary evil though, because without them then you'd have to check regions (or zones) to see if 1PM in China is the same thing as 1PM in Australia is the same thing as 1PM in Bolivia.
Aren't time zones quite straightforward? You add a whole number of hours and for some a half. Compare that to a sundial on the one side and having times that don't match your day at all on the other, I'd say it's good
Inagine going back hundreds of years to convince everybody in the world to use the same time. "No I know not everybody has a clock, but if you could consider sunrise midday that would make my job in the future much easier."
It’s only bad when used incorrectly. Just store time in UTC and convert it to timezone of your setting to present it. Most modern languages offer a library that makes it just one more line of code. Not only it’s then clear and unambiguous, it supports all timezones.
Video is a lecture about how to think about dates and times, through the lens of a specific open source .NET library designed to aid with applying that thinking. It points out how most languages' standard libraries really work against you, because they conflate different concepts. For example, an Instant (a specific point in time, globally recognised) and a LocalDateTime (a date and time in a way that is irrespective of your location—for example you might want your alarm to wake you at 8:00 am on weekdays, and still do that if you move to a different time zone), a ZonedDateTime (a date and time tied to a specific location—like if you want to say "the meeting starts at 10:00 am Oslo Time"), and an OffsetDateTime (a date and time tied to a specific UTC offset—which is not necessarily the same as a time zone, because "Oslo Time" is a time zone that doesn't change, but its UTC offset might change if they go in or out of DST, or if a place decides to change, like how Samoa changed from UTC-11 to UTC+13 in 2011.
These are all subtly different concepts which are useful in different cases, but most libraries force you to use a single poorly-defined "DateTime" class. It's easier and requires less thought, but is also much more likely to get you into trouble as a result, precisely because of that lack of thought, because it doesn't let you make a clear distinction about what specifically it is.
His library is great for this, but it's very worth thinking about what he's talking about even if you don't or can't use it. As he says in wrapping up:
You may be stuck using poor frameworks, but you don't have to be stuck using poor concepts. You can think of the bigger concepts and represent all the bits without having to write your own framework, without having to do all kinds of stuff, just be really, really clear in all your comments and documentation.
The notifications in one of our systems is aligned with UTC because it needs to be for a whole bunch of background services to function. Periodically (every couple of years) someone raises a ticket to complain that the time of their notifications is an hour out, and the 2nd line support worker will think "well that's easy, I'll just change the server time to BST". This then brings this whole suite of applications to a crashing halt as everything fails.
Worst is when someone fucked up the DB time configs at some point and you have datetimes in a column that fall during the “nonexistent” hour in which clocks skip ahead for DST, and you have to figure out what the fuck actually happened there, and where in the data pipeline tz data was either added or stripped (sometimes it’s both, and sometimes it’s not just once), and undo the timestamp fuckery.
Source: did that this week. Was not super awesome.
Na let's keep timezones, there useful for humans who generally want time to mean something, but lets ditch daylight savings time, all it does is make scheduling a massive pain twice a year, and messes up everyone's sleep cycle. Without it, timezones would just be a fixed offset from another, minimizing trouble.
I don’t know what the hate is unless you are trying to store time as a String property. There a special place in hell for all developers who do this.
IMHO, all you really need to know is an Epoch time stamp and whether it’s localized to the viewer or the creator… Not that complex. The problem with time zones is that politicians keep changing them
Honestly, I’d rather give the creator of NULL a slap.
IMO, the biggest problem with timezones is that the people who initially created them were fairly short sighted.
That and there have been way too many changes to who lives in what timezone. The one that boggles my mind is that apparently there's a country in two timezones, not like, split down the middle or anything, but two active timezones across the entire country depending on which culture you're a part of, or something. It's wild.
I still don't know if there's any difference between GMT and UTC. I couldn't find one. They both have the same time, same offset (+0), and represent the same time zone area.
I use UTC because I'm in tech, and I can't stand time formats, so I exclusively use ISO 8601, with a 24 hour clock. Usually in my local time zone, via UTC. We have DST here which I'm not a fan of, but I have to abide by because everyone else does.
My biggest issues with time and timezones is that everyone uses different standards. It drives me nuts when software doesn't let me set the standard for how the time and date is displayed, and doesn't follow the system settings. It's more common in web apps, but it happens a lot. I put in a lot of effort to try to get everything displaying in a standard format then some crudely written website is just mm/dd/yy with 12h clock and no timezone info, and there's nothing you can do about it.
OMG, I'm dealing with a developer right now that is dealing with patient collected samples in several timezones, allowing the patients to either enter the time they collected, or use current time, and storing it in UTC time.
We do not receive any timezone data, patient collection data is showing different days than the patient could write on their samples depending on the time of day, and the developer said 'just subtract X hours' (our timezone).... for which not all patients would live in.
I suppose I could, if they'd provide the patient's timezone, but they don't even collect that. Can you just admit your solution is bad? It's fine to store a timestamp in UTC, but not user provided data... don't expect average users to calculate their time (and date) in UTC please.
I would truthfully and happily go back in time and tell people not to waste with the fucked up bullshit technology of the past. I mean Angular 1, what the hell was that? Twitter integration? Fuck you 2010. Zend Framework? You should be hanged. HANGED.
My suggestion has always been universal sidereal time. It is singular, doesn’t change, and carries no colonial baggage since it rotates around the whole earth. Even suitable as a home time if we become spacefaring.