Before timezones and trains, each town has its own natural time (based on the sun or whatever). Would you have preferred that?
tbf there are libraries capable of handling that too, like rust’s chrono
I used to feel this way. Over the course of building out 2 calendar systems in my career (so far) and having to learn the intricacies of date and time-related data types and how they interact with time zones, I don’t have much disdain for time zones. I’d suggest for anyone who feels the same way as this meme read So You Want To Abolish Time Zones.
Also, programmers tend to get frustrated with time zones when they run into bugs around time zone conversion. This is almost always due to the code being written in a way that disregards the existence of times zones until it’s needed and then tacks on the time zone handling as an afterthought.
If any code that deals with time takes the full complexities of time zones into account from the get-go (which isn’t that hard to do), then it’s pretty straightforward to manage.
This did little to convince me that timezones are an unnecessary construct. Pretty much every point made was done from the perspective of someone who had already decided their opinion rather than objectively weighing the pros and cons.
Yeah, the article is written like it’s parodying those who want to abolish timezones, but I’d be interested in specifically what you found unconvincing? I read the main point as being that time zones are an arbitrary social convention but that that arbitrary social conventions are pretty useful for humans.
Like one thing that the article does is repeatedly asking the question “but what time is it in Melbourne?” which I guess sounds pretty silly if you think timezones are unnecessary, since the question would be meaningless if timezones were abolished, and people in different parts of the world would already have centered their day around their respective parts of the clock and you would just look up what the times for everything are in another place. But I think the author was kind of already discarding that idea, because it’s just equivalent to timezones - you have a lookup table for each part of the world to find out what people do at a certain time, except instead of being a single offset you have like a list of times like “school openings”, “typical work hours”, “typical waking hours” (?) etc. This system is basically timezones but harder to use for humans. So the author asking “but what time is it in Melbourne?” is in the context of this table not actually existing, because if it did, then you haven’t actually abolished time zones.
Yeah but also if we’re being honest, from a programmer perspective the timezone has no bearing on what you do, and is hence not a problem at all.
After all, much like you translate the language of your UI when displaying in X, you also add Y hours to all times shown in X. Done. You wouldn’t even need to persist the zoned time data anywhere, given their static nature you could decide the final timestamp shown at display time, purely on a client, visual, level.
OTOH, daylight saving time turns itself - and timezones - into an utter mess and whoever invented them hopefully is proud of the raw amount of grief and harm they caused the world. It causes all kinds of issues with persistence, conversion and temporal shifts in displayed time due to the ephemeral nature of the +X minutes added. Or not. That’s the worst part.
So timezones: Fine, it’s just bling bling on display anyways.
DST: Burn it at the stake.Yeah, I’m in agreement that DST is kinda pointless and could probably be abolished, but the thread is about abolishing timezones in general (or so I thought).
Abolishing DST doesn’t eliminate all the weird issues with “ephemeral” offsets though. Suppose the user wants to set a reminder for a recurring event at 3pm, and then moves to another country. Do you keep reminding them at 3pm in the new time zone or the old time zone? Maybe the reminder was “walk the dog” and the user meant for it to be at 3pm local time, or maybe it was “attend international meeting” and the user meant it to be at 3pm in the original timezone. (This admittedly only happens to calendar apps so isn’t something that most applications have to deal with, unlike displaying timestamps in general.)
But other than that, I’m of the opinion that as programmers we’re supposed to model the problem space as best we can and write software that fits the problem, rather than change the problem to fit our existing solution. After all, software is written to be used by humans, not the other way round (at least not yet). So if DST is something those wacky humans want and use, then a correct program is one which handles them correctly, and a programmers job is to deal with the complexity.
I disagree about the table - if you’re interacting regularly across timezones you tend to convert everything to your local time anyway - India’s on lunch at 9am, US is starting at 14:00, because that’s how it fits into your day.
I agree. It’s written like “ugh I’m used to timezones, now what?”.
I agree with you. Every language I’ve used in the past 15 years has a datetime library or at least standard cookiecutter functions available for conversions, calculations, and adjustments for leap years and daylight savings. Store everything as a datetime in a ISO format with TZ offset or a Zulu indicator, and just convert on the client end if you need to, with a toggle for UTC/local and an option to choose your preferred local.
If you have some exotic or fuzzy edge case requirement like alternative calendar systems or dates before and after the Julian - Gregorian changeover, the wheel has already been invented and there’s a decade-old stackoverflow thread discussing it ad nauseum, with a 200+ point answer that gets updated every couple years as new tools or major updates become available.
Time zones are part of it, but also daylight savings is a real pain in the ass. And like you said it gets particularly complicated when you’re dealing with a system that deals with these things as an afterthought, which seems to be a lot of older libraries for time. For instance, the Java date utils are a nightmare and are now considered semi deprecated replaced by a new java.time api. That is, of course, no help for the ridiculous amount of things that depend on these stupid date utils and no one wants to spend the dev hours to refactor.
DST had good reasoning at the time. It doesn’t anymore.
The US tried no dst back in 1970. After 2 years people wanted it back.
Is it still 1970 today?
What is so different today that people wouldn’t change their mind again about DST?
It’s 54 years later. Are you expecting a full list or something?
So because you read the news on your phone instead of the newspaper somehow everything is different with the sunrise?
You’re right. The only thing that has changed is that newspapers are smaller.
If the list is so long, then it should be easy to list one thing that is different today that would make people not want DST.
I don’t need a list. Just one example.
They did permanent DST instead of no DST (permanent standard time), so they had dark mornings in winter.
Except if there was only one zone of time that would be hell to program too because then you would need to check for different times of day for different locations. I think programming is just difficult lol
you would need to check for different times of day for different locations
You have to do that now with time zones anyway.
I think thu comment was more about phases of the day. Like for example, your phone might come pre-installed with a sleep mode from 23:00 to 06:00, which is roughly fits for most users. Should we use UTC everywhere, then you’d have to have different presets for different parts of the globe.
Or say you wake up just a bit after sunrise at 7am everyday and you fly across the continent for vacation. Now you have to change all you alarms because sunrise is suddenly at 3am.
Or what if you’re writing a book and you want to tell the reader what time it in: 15:00 will mean something else to readers around the world. And while you could attempt to cover it up with “15:00 it the afternoon”, there will still be a disconnect between your words/intentions and what the reader pictures.
UTC would be a bliss for programming and scheduling events in this funny little globalized world, but as animals we still base our days on the burning fireball in the sky and removing that connotation from our timekeeping messes with linguistics and clear communication.
I don’t think the system we have is perfect either, but I don’t think employing UTC everywhere is the way and I don’t have other suggestion either.
and then boom congratulations you just reinvented time zones except worse, & everyone’s gonna do their own way and they’re all gonna be slightly different.
but at least your code will be simpler. oh, wait…
…but it would be the same time in different locations? E.g. at the time I’m writing this it’s 660DFD56 in New York, London, Moscow, Tokyo, Moon, Mars, Andromeda etc.
I would have stern words with John Riccitiello the ex Unity CEO who really neglected the core of their business for the years he was there. He was fired not too long ago. Games from scratch covered the conclusion of that train wreck. The new CEO seems to get that they need to refocus on the engine and making it better for developers versus chasing money. https://youtu.be/woTLLrgywwE?si=BIXTJGGMjpjv72vO
DST is a digital STD
The guy that invented time zones was solving a problem where each little town had their own time standard. I don’t think that was sustainable.
Would be more appropriate if it was the datetime library creator.
The UK press every year makes a huge song and dance in opinion pieces about getting rid of DST. However I’m always horrified to see that people want us to keep British Summer Time instead of Grenwich Mean Time. I understand that there are “longer evenings” in BST; however we literally invented GMT and coerced the rest of the world to adjust their times based on that. From the point of view of being constantly compatible with UTC and having more consistent business hours for international companies it makes more sense to me if we kept GMT.
Also the longer evenings thing can be achieved by simply staying up an hour later. It’s not exactly like an hour is being stolen from you when the times switch, the change of clocks are mainly pointless admin.
Lastly I read an article recently that described a correlation between the incidence of heart attacks and the clocks changing. The theory is that just slightly messing with people’s sleeping patterns can cause additional strain on the body.
Another point for GMT, in the mid '70s, the US went onto DST year round for a couple years. People hated it so much they changed back to switching the time.
If we wanna do away with DST and BST, we need to go back to standard time, as the later sunset in the summer translates to no sunlight for workers in the winter
No the longer evenings are achieved by work starting and ending an hour earlier. And it’s literally easier to change the time zone than to change corporate culture.
So would you be team BST if we had to pick one? I’m just personally not sure it’s such a loss when the sun is out until 10pm at the height of summer.
Edit: to be honest that would probably be my 2nd preference. Anything except the system we have now where the clocks change!
I think I want work to end an hour earlier in the winter because of how early the sun sets, and care much less about the summer. So however it’s done, it would be great if office jobs could happen when it’s dark outside and we could live our lives during daylight.
There are some time libraries which actually work pretty well and allow you to manage things like Timezones. And then there are some abominations beyond my compression…
Have you tried 7zip?
I just discovered that while the ServiceNow APIs return all times in UTC, they use the user’s default time for all times passed in as a parameter.
So if your account is set up in PDT and you say “give me this item that I just created”, it will say “here your item, this was created at 17:00”.
But if you say, “cool let me see all items created in the last hour, so anything greater than 16:00”, then it will respond “got nothing for ya, chief.”
Leap year creator has left the chat & blocked…
Leap years are not as bad as timezones, if you think about it. Timezones try to imperfectly solve a local problem - how to match your clock with the position of the sun. Leap years try to reasonably solve a global problem - how to keep your calendar aligned with the seasons.
I identify as a time radical. We should switch the entire world onto GMT; +/- not a goddamn thing. Is it perfect? I think so, but all those people who might be confused will probably find it a lot less confusing than trying to make sense of the difference between timezones.
GMT has leap seconds. TAI does not. Switch world to TAI.
