The only code with timezones should be the bit squishy meat bags touch. Everything’s is should be UNIX time. Or it you are unfortunate enough to be on Windows, NT time.
Some unfortunate programmers already have to deal with the speed of time not being a constant. In a distant future, timestamps might always have a universal position (and speed), and is that much different from timezones?
Or we find some way of removing time distortion of physics. Find the universe’s real systick. 😃
No UTC. Convert/use UTC on the way in and covert to local time for the user or local time of the noun the date is for in the display.
DST is a digital STD
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.
I’ve just said 'fuck it’s and switched all my clocks to UTC. I don’t even care anymore.
Why not metric time(TAI)?
Is that supported in any common operating systems?
Or why not just seconds past the epoch?
leap second corrected or not?
Metric seconds or UTC seconds?
I’m gonna say SI
Reasons just states difference, but does not answer why.
There’s literally a section titled ‘why use UTC - not TAI?’.
On the other hand, TAI does not take into account the variations in Earth’s rotation speed, which determines the true length of a day. For this reason, UTC is constantly compared to UT1. Before the difference between the two scales reaches 0.9 seconds, a leap second is added to UTC.
On average, Earth has been slowing down a bit over the past decades, so UTC is currently running 37 seconds behind TAI.
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.
Soon we’re going to have a new timezone for the moon. Yay, I guess?
Surely they will just use utc?
Can’t be that simple due to time dilation effect. Time moves at a different rate in moon, about 1s difference per day.
https://www.reuters.com/science/white-house-directs-nasa-create-time-standard-moon-2024-04-02/
That article says 58.7 microseconds per (Earth) day. Not 1s.
Shit you’re right, I misremembered it.
Appreciate you correcting your post, just one more needed.
ms = milliseconds
us = microseconds
Easier to just round up lol
not a programmer myself, but actually fuck you, UTC was the correct choice, anything that isn’t UTC is a wrong choice, and i will literally fight to my death over this.
Timezones are dumb and stupid, and you cannot convince me otherwise, so far the single best argument i’ve heard is “well actually, the hands on a clock and the numbers themselves roughly represent the cycle of the sun in the sky during the day.” Which is pretty good, until you realize that clocks tend to be circles, and you can often just rotate them. And suddenly, the numbers now match up perfectly. But i’ve also never once heard of someone caring about that specific feature, so uh. Good riddance frankly.
Timezones kind of made sense back in the day, when the sun was the only realistic timing system, and pre internet, when people stayed where they were. But now that people don’t do that, and the internet tends to do this thing where it exists. I refuse to believe it makes more sense to have timezones than not.
“Hmmm yes please, i would like to order the time here, but halfway across the globe please” - statements dreamed up by the utterly insane.
ok that concludes my rant. Now i’m going to go set FUCKING DAYLIGHT SAVINGS TIME on my clock because FOR SOME REASON THE TIME JUST CHANGES HALFWAY THROUGH THE YEAR FUCK YOU.
My man.
The fact that i even have to think about timezones at all is hilarious to me. Jet lag? UTC would fix that, the time ANYWHERE you are is the time you are normally at, it’s just the day/night cycle that’s bunk. So now instead of being confused as to why things are pretty normal, but you feel utterly shit. You just feel very confused, and probably still tired, but it’s very obvious why.
This shit sends me into schizophrenic ramblings i swear to god PLEASE stop using timezones.
Don’t think your username checks out, seems like time is killing you
No. Thats why im killing IT. Because it fucking sucks, and i hate it, and it should die.
I know I’m probably not changing your mind on this but interested in how you would want the system to be? Regarding your point about being able to rotate the clock so it matches the local solar cycle, suppose we’re in a place where we have 13, at the top of the clock, because that’s when midnight is where we are.
And let’s say it’s Wednesday 3rd April today. What happens when the clock reaches 13? After 1 second elapses, does your local clock go from Wednesday 3rd April 12:59:59 to…
a) Wednesday 3rd April 13:00:00 b) Thursday 4th April 13:00:00
If a) then you have the problem that the date change is now in the middle of the day, and most of the time you can’t even say “what day is it today”. (If 13:00 is midnight, then 00:00, when the date would roll over, would be just before noon.) You have to say today is "Wednesday/Thursday, or “3rd/4th April” because when you wake up it’s Wednesday, but after lunch it becomes Thursday.
If b) then you have the problem where it may be Thursday 4th April 13:00:00 where you live, but actually it’s not midnight yet somewhere else and so simultaneously it’s Wednesday 3rd April 13:00:00 there. And in fact every location has their own time at which the date rolls over and it’s not even possible to interpret a timestamp unless you have a table that tells you when midnight is for each location.
Maybe you feel that one or both of these are not really big enough of a problem, or maybe you can think of some other way of dealing with this that I haven’t thought of. And yeah, both of these issues sort of happen already with timezones – the issue in a) happens if you stay up past midnight, but at least it always happens at midnight at not when most people are awake and doing their business. The issue in b) sort of happens already since it can be Wednesday in one place and Thursday in another, but at least the timestamp would always indicate how many hours past the date rollover it is.
Thank you! Drives me up the wall that when people suggest this and they haven’t thought it through, and that it might make other things worse.
I’d say for everyday usability, what we have is way better. Sure, you deal with timezones, but at least once you know what time it is there you have a good sense of what part of the day they are in.
Currently you look up the timezone, maybe do some maths (but let’s be real, you just search and get given the time) and then you immediately have a good sense of what the time is there, oh cool it’s 7AM.
If we all had the same timezone: you look it up, and then you HAVE to do maths. Why? Oh their midnight is 8, and it’s 15 now, so 7 hours after midnight.
Your mind immediately has gone to oh it’s 7AM, but NO, in this new reality, it’s 15:00 everywhere and where you live midnight is 14:00, so that means where you live it would be like your 21:00.
No matter what time you pick to anchor what time of day that place is, the problem persists. And now you just have replaced the problem of looking up timezones, with looking up when the sun is at some point, and then needing to convert that to get a sense of what time it is there according to the sun.
This would be shit, when you get to a new country when travelling you have to relearn what the numbers “feel” like.
Let’s just keep what we have, this is a solved problem.
timezones IMO, shouldn’t exist. The sun cycle is disconnected from actual physical date and time cycle. Just pick a timezone, UTC, or whatever the fuck, unix time, i don’t care, DST or not, i don’t care, and stick with it.
Nothing, the next day is 00:00 You’re adjusting it to match the rising cycle of the sun, not to match the day transition point which is entirely arbitrary, that would just be different. I mean, take a normal clock, flip it upside down. Does it run any differently? Nope. It’s the same, it’s just upside down now.
The date time roll over would be a little weird, but then again we literally already have it. It’s just not synced with the sun cycle. Ask anybody who rolls a late night schedule what they think about midnight. I mean you literally can say what day it is. The date is explicit. The date changes at night, can you say what night it is at night? It literally doesn’t matter.
The date cycling over is universal across every zone, doesn’t change from one place to another. It’s the cycle of the sun that changes. That’s the easy part to adapt to, we’ve been doing it since the beginning of humanity.
then you have the problem where it may be Thursday 4th April 13:00:00 where you live, but actually it’s not midnight yet somewhere else and so simultaneously it’s Wednesday 3rd April 13:00:00 there.
Yeah, we already have that, it’s called timezones. The day night cycle is independent from date time. To TL;DR that entire section, midnight literally just isn’t a thing in that scenario. It’s the date rollover point now.
Like frankly, someone who lives in the midwest, with DST, and long days in the summer, and shorter days in the winter. None of this is a problem. We’ve been collectively doing this async sun cycle/date time thing for centuries. The sun here sets about 3-4 hours later in the summer, in the winter it’s about much earlier comparatively. We adjust our clocks to this twice a year, every year, for every decade, for every century. Our bodies adapt to it. Nothing explodes. (even though arguably it still sucks.)
The problem you list there specifically i think is mostly confusion about the concept of midnight not being midnight anymore, midnight is just called that because it’s the middle of the night, we just happened to choose that as the point where the day rolls over. Sun rise and sun set happen at specific times, weather apps will tell you about this. Nobody seems to complain about those being incredibly variable.
The date rollover is the same in every place in the world. You local day/night cycle is what is disconnected. I could see that potentially being annoying, but then again, we already have concepts of morning, noon, afternoon, evening, etc… I’m genuinely not sure how much this would matter in day to day life. You wake up, it’s one day. You wake up the next day, it’s the next day. You just happen to be awake at the point that it happens. I mean hell it probably wouldn’t even bother most people. Lets say day rollover is noon in 24 hour time somewhere. You tell someone to show up 15:00 on the 8th, which is an impossible date, you just automatically go ok that’s “today” everything before 12 in that scenario is the 7th, everything after is the 8th. 15:00 on the 7th literally isn’t a time that can exist. It’s automatically the 8th. and the advantage here, is that the date rollover point, is the same EVERYWHERE. It literally does not matter where you are on earth.
12 is the rollover point in finland, it’s the rollover point in siberia, it’s the same in china, africa, america, south america, etc… The ONLY thing that has changed is the offset of the day/night cycle in relation to the date/time cycle.
I’m quite confused as to how you’re actually proposing the time should work. I assume that when we talk about abolishing timezones, we mean that everyone switches to a single standard timezone (and that it still goes from 00:00 - 23:59). Are you saying that you would like:
a) The date-rollover point to happen at local solar midnight (i.e. 12 hours past when the sun is highest in the sky in your location, or roughly that), regardless of what the time actually is
b) The date-rollover point to happen at 00:00 standard time, but most people still wake up and go to sleep roughly around when the sun rises and sets
c) The date-rollover point to happen at 00:00 standard time, but most people wake up at roughly 07:00 (for the sake of argument, it could just be any standard time) and go to sleep roughly 22:00, regardless of where the sun is at those times
d) Some other scenario that I didn’t think of?Maybe I suck at reading comprehension but I can’t tell which system you’re advocating for. I’m also confused when you give the example “15:00 on the 7th literally isn’t a time that can exist”, because however your system works, surely if 15:00 on the 8th is a time that you can refer to, then 15:00 on the 7th is just the time 24 hours before that? (I’m actually just very confused by your scenario. Are you referring to noon as the local solar noon, i.e. when the sun is highest in the sky, or are you referring to when the clock reads 12:00? In both cases I can’t figure out a way to make “15:00 on the 7th” impossible.)
Also I don’t think that the sunrise/sunset times being different throughout the year or that DST exists are indications that the solar cycle is independent of the date. Even if the sunrise/sunset happens at different times of the year, timezones are clearly meant to roughly center the waking day either side of 12:00 on the clock around the solar noon. DST exists to make sure that people get more sun during the afternoon when people are more active, so that both contribute to that the date-rollover point happens when it’s dark out and people are less active.
Timezones are dumb and stupid, and you cannot convince me otherwise, so far the single best argument i’ve heard is “well actually, the hands on a clock and the numbers themselves roughly represent the cycle of the sun in the sky during the day.” Which is pretty good, until you realize that clocks tend to be circles, and you can often just rotate them. And suddenly, the numbers now match up perfectly. But i’ve also never once heard of someone caring about that specific feature, so uh. Good riddance frankly.
This is an interesting thought:
If we had UTC before we decided on a lot of modern standards - by whatever means we got it - I wonder whether it would have just evolved that Celts are used to the sun rising at 4-10 on the clock, but an Ainu is entirely used to the sun rising at 13-19.
Move to International Atomic Time timezone.
clock_gettime(CLOCK_TAI, ...)and stop complaining.Worked on a project where devices just magically froze, but only during the month of February!
Turned out the people who had written the firmware had decided to do their own time math to save space and had put in an exception in the code for leap year values. Except instead of February 29th, it kicked in for the whole month. And the math was wrong so you ended up with negative values.
The product was due for launch in March of that year and was headed to manufacturing. It was by sheer luck that someone ran a test on February 1st and caught the problem.
Don’t mess with time in code, kids.
This is why we have pre-built libraries and Unix time.
Unix time.
Unix time doesn’t help with timezones… It’s always in UTC.
Unix timestamps also get a bit weird because of leap seconds. Unix timestamps have no support for leap seconds (the POSIX spec says a Unix day is always exactly 86400 seconds), so they’re usually implemented by repeating the same timestamp twice. This means that the timestamp is ambiguous for that repeated second - one timestamp actually refers to two different moments in time. To quote the example from Wikipedia:
Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 1483142400 is thus ambiguous: it can refer either to start of the leap second (2016-12-31 23:59:60) or the end of it, one second later (2017-01-01 00:00:00). In the theoretical case when a negative leap second occurs, no ambiguity is caused, but instead there is a range of Unix time numbers that do not refer to any point in UTC time at all.
Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it’s modifying the length of a second.
Aren’t timestamps fun?
Luckily, the standards body that deals with leap seconds has said they’ll be discontinued by 2035, so at least it’s one less thing that developers dealing with timestamps will have to worry about.
Don’t try to write your own date/time code. Just don’t. Use something built by someone else.
Luckily, the standards body that deals with leap seconds has said they’ll be discontinued by 2035
Did they figure out a way of making the earth spin more reliably per how the humans want it to?
If I remember correctly, they’re updating the standards to allow for more deviation between UTC time and “actual time”. They’ll likely replace leap seconds with a leap minute that happens much less frequently, implemented by spreading it across the whole day, similar to the leap second workaround I mentioned.
Unix time doesn’t help with timezones… It’s always in UTC.
Unix timestamp is always in UTC which is why it’s helpful. It’s seconds since Jan 1st 1970 UTC. Libraries let you specify timezone usually if you need to convert from/to a human readable string.
Don’t try to write your own date/time code. Just don’t. Use something built by someone else.
…yes that’s why UNIX timestamps are helpful, because it’s a constant standard across all the libraries.
Some systems instead spread a positive leap second across the entire day (making each second a very very tiny bit longer) but technically this violates POSIX since it’s modifying the length of a second.
Then that system should be trashed.
Unix timestamp is always in UTC which is why it’s helpful.
Any time you show the time to a user, you have to use a timezone. That’s why the unix timestamp has limited usefulness - it doesn’t do a lot on its own and practically all use cases for times require the timezone to be known (unless you’re dealing with a system that can both store and display dates in UTC). Even for things like “add one week to this timestamp”, you can’t do that without being timezone-aware, since it’s not always an exact number of seconds as you need to take Daylight Saving transitions and leap seconds into account.
Then that system should be trashed.
A lot of systems just don’t handle leap seconds well. Many years ago, Reddit was down for four hours because their systems couldn’t deal with leap seconds. Smearing the extra second across the whole day causes fewer issues as software doesn’t have to be built to handle an extra second in the day.
Unix timestamp is always in UTC
Careful with the exact phrasing here - while the epoch was at midnight in GMT, the time from which time_t is measured also exists in other timezones.
Then that the library that does it should be trashed.
UNIX time is trash.
too bad unix time only has 14 years of life left in it.
No
Embedded portable device with a teeny ARM processor. Sadly, no room for linux anything or even an RTC. Every time it connected to a phone, the phone would set its clock so the timestamps were somewhat close to being accurate.
However, if you swapped out the AAA battery and DIDN’T connect it to the phone at least once, all your subsequent readings would go back to zero epoch and would be forgotten 🤷🏻♂️
Good times.
Some absolute and utter legend of a man made a Unix kernel for the fucking ZILOG Z80, you have no excuses
(It’s called UZI and it’s written in K&R C for some obscure CP/M compiler)
If it had been up to me, I would have included a proper real-time-clock in the design and done things a lot differently.
But the device was designed by one company and the BLE and processor module by another. For some ungodly reason neither trusted each other, so nobody was given access to the firmware source on either side. I worked for a third company that was their customer paying the bill. I was allowed to see the firmware for both sides, but only read only, on laptops provided by each company, one at a time, in a conference room with their own people watching everything. Yeah, it was strange.
I was there because the MCU and the BLE processor sometimes glitched and introduced random noise. Turned out the connection between the two parts were unshielded UART with no error detection/correction 🤦🏻♂️
It was concidental that we hit the date glitch. Took all our effort just to get them to add a checksum and retry. The tiny MCU was maxed out of space. No way to fit in any more code for date math.
God I’m sorry you had to go through that much middle management bullshit
Thanks. On the plus side, I got to try ‘soup dumpling’ – still the best I’ve ever had. And Kaoliang, the most gut-busting distilled beverage known to mankind. OTOH, the product shipped, won lots of awards, and got national coverage for the company.
Nothing to do with timezones, but still, fun times.
Was it related to banking?
Consumer health.
Good product, too. Won a bunch of awards. Unfortunately, the company has since gone out of business.
Ok so there are 24 time zones. Before that every town had their own time based on the sun. We basically went from infinity time zones down to 24. This is in fact simpler.
(There are some half hour time zones too,(India, Newfoundland) so at least 26.)
there are 24 time zones
Cunningham’s law says that this will generate some discussion in the replies!
There are a few time zones that are 45 minutes off, like Nepal Standard Time which is UTC+5:45, some places in Western Australia and South Australia use UTC+08:45 and the Chatham Islands are at UTC+12:45 or UTC+13:45 in summer.
Absolute madness. smh my head
DST means you also have things like CST vs CET and given some places start DST earlier or later than others and some ignore it all together, we probably have at least 50 time zones.
Always fun trying to schedule international regular meetings when suddenly there’s a week when half the people’s times changed and the other half’s times haven’t yet, so you try to figure out which time would exclude the fewest essential people.
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
…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.
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…
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?
But if time travel is a thing, imagine the whole new time nightmares! Oh you went back a year with your phone? Now all your TLS root certs are invalid because you’re before the start date. Or you have files/emails/whatever that are dated in the future. I guess you can get to that state by just setting your clock forward but I imagine some stuff would break.
I worked on a project that had a few spots where we compare a saved timestamp to the current time. During testing, the client would randomly change their device time a few days forward or backward and complain that things weren’t working as expected. I had to explain to them multiple times that they were basically time traveling, and the program was actually handling it fairly well all things considered.
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.
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.
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.
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.
I agree. It’s written like “ugh I’m used to timezones, now what?”.
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.
