Tell HN: Sudden Chile daylight savings time rules change causes chaos
173 comments
Not the worst example I've heard. In 2016 the Haitian president canceled daylight savings by decree two days before the changeover. I was flying out of the country the morning after the change, and had a really hard time explaining to airline customer service (who hadn't gotten the memo) what exactly the problem was.
"When does my flight leave?"
"At the scheduled time."
"According to what clock?"
"Huh?"
I just showed up an hour early.
"When does my flight leave?"
"At the scheduled time."
"According to what clock?"
"Huh?"
I just showed up an hour early.
Morocco did the same thing in 2018 - less than two days' notice. https://www.bbc.com/news/world-africa-45995634
petre(1)
Haha.
My wife and I, we once had three switches to daylight saving time one spring. This was during a trip to the US. Once in NYC where we missed our train. Once in Arizona, we just arrived one hour "later" than planned. The last time after we returned to Switzerland. I missed an important meeting at my job still jetlagged.
That was confusing as hell even without rule changes.
My wife and I, we once had three switches to daylight saving time one spring. This was during a trip to the US. Once in NYC where we missed our train. Once in Arizona, we just arrived one hour "later" than planned. The last time after we returned to Switzerland. I missed an important meeting at my job still jetlagged.
That was confusing as hell even without rule changes.
And when did it depart?
At the scheduled time
I honestly don't remember!
Somewhat saved by the fact that the world pretty doesn’t pay much attention to what does or doesn’t happen in Haiti
Which is unfortunate. More people should know about the atrocities heaped upon Haiti by the "civilized" French [1] and Americans [2].
1. https://en.m.wikipedia.org/wiki/Haiti_indemnity_controversy
2. https://en.m.wikipedia.org/wiki/United_States_occupation_of_...
1. https://en.m.wikipedia.org/wiki/Haiti_indemnity_controversy
2. https://en.m.wikipedia.org/wiki/United_States_occupation_of_...
Chilean here. Unfortunately our governments have had the bad habit of changing the date DST starts on every two-three years, and that wreaks havoc everywhere in the country. We are kind of used to having a couple of days where we assume everyone will run an hour late because of this.
I just hosted some Peruvian friends this week and were amazed at the kind of power the government wields just by having the ability to change our timezone.
We should be placed on GMT-5, but for a couple of reasons we are on GMT-4 and GMT-3 for DST. Our country is so long that some places on the north have normal length days but on Patagonia days are shorter and they prefer to be on DST all year long (and since some years ago we have a different timezone for that area).
I just hosted some Peruvian friends this week and were amazed at the kind of power the government wields just by having the ability to change our timezone.
We should be placed on GMT-5, but for a couple of reasons we are on GMT-4 and GMT-3 for DST. Our country is so long that some places on the north have normal length days but on Patagonia days are shorter and they prefer to be on DST all year long (and since some years ago we have a different timezone for that area).
So that's why `tzdata` constantly gets updated.
So far 3 releases in 2022, 5 in 2021, 6 in 2020, 3 in 2019
as someone who lived in Chile for 3.5 years, I can tell you that all developers who use tzdata = a gift from God.
Calendly always seriously struggled with it, which is really bad given they're a scheduling tool. The amount of meetings I (or my guests) came 1 hour early/late to was... too many.
Calendly always seriously struggled with it, which is really bad given they're a scheduling tool. The amount of meetings I (or my guests) came 1 hour early/late to was... too many.
> We are kind of used to having a couple of days where we assume everyone will run an hour late because of this.
Why not just specify times are given in winter time? Invite someone over for "19:00 winter time" rather than just "19:00".
Basically, "amazed at the kind of power the government wields" only works if people follow it. You don't have to put up with that crap (until the dust has settled) when using a time zone people already know: whichever one you've been using for the past ~6 months. (That is to say, this doesn't sound like a religious country type situation where the religious leader declares a new year randomly and you could be seen as not following the holy law by using a more predictable calendar. I vaguely remember something about Israel and Windows 9x just not supporting it until the country decided these things with reasonable lead times.)
Why not just specify times are given in winter time? Invite someone over for "19:00 winter time" rather than just "19:00".
Basically, "amazed at the kind of power the government wields" only works if people follow it. You don't have to put up with that crap (until the dust has settled) when using a time zone people already know: whichever one you've been using for the past ~6 months. (That is to say, this doesn't sound like a religious country type situation where the religious leader declares a new year randomly and you could be seen as not following the holy law by using a more predictable calendar. I vaguely remember something about Israel and Windows 9x just not supporting it until the country decided these things with reasonable lead times.)
For comparison, it looks as if Punta Arenas ("the most southerly city in Chile" according to Wikipedia) is about 53 degrees south.
53 degrees north puts you around Nottingham, England (or a little north of Berlin).
53 degrees north puts you around Nottingham, England (or a little north of Berlin).
Can you link the article to see why it would say that? Puerto Williams is a lot further south.
But Magallanes doesn't really matter, they don't have DST.
But Magallanes doesn't really matter, they don't have DST.
To save everyone else lookup trouble since I did: Puerto Williams has about 3k people and the other one has a 125kish.
[deleted]
> amazed at the kind of power the government wields just by having the ability to change our timezone.
Who else would have that power, though? Every government has the power to set the time within their own borders.
Who else would have that power, though? Every government has the power to set the time within their own borders.
i think the point isn't that somebody other than the government should have that power, but that the government should have less of that power.
it's perfectly reasonable for goverments to self-limit themselves - for example, pass a law that daylight savings time can't be changed with less than 6 months notice.
it's perfectly reasonable for goverments to self-limit themselves - for example, pass a law that daylight savings time can't be changed with less than 6 months notice.
But if not the government, then who? And what is their basis for that power? Do you want a separate election for just the people who decide timezones?
I've got to admit, there's an organisation deciding the grammar rules of the Dutch language, and I frequently disagree with them. I wouldn't mind being able to vote for more sensible spelling rules.
I've got to admit, there's an organisation deciding the grammar rules of the Dutch language, and I frequently disagree with them. I wouldn't mind being able to vote for more sensible spelling rules.
Not if everyone uses mean solar time... or just chooses something like GMT.
…which they would do via government.
there are areas of the world where the government disagrees with the population on the appropriate timezone, most notably in Xinjiang
https://en.wikipedia.org/wiki/Xinjiang_Time
https://en.wikipedia.org/wiki/Xinjiang_Time
The exception that proves the rule.
A someone who is living in a country where the chosen timezone is 3 hours ahead of solar time, I wish governments had NO authority whatsoever over timezones.
Didn't they do the same thing in 2011? But as I recall, it was the Friday before the time change that the announcement came out. I had just recently moved to Chile, and I remember a week of looking at Google to find out what the current time was.
> GMT-3 for DST
So, for a few months every year clocks at Chile are synchronized with the the (almost) most Eastern parts of South America? (Except for some small islands.)
That's insane. Does the Sun sets at 10PM?
So, for a few months every year clocks at Chile are synchronized with the the (almost) most Eastern parts of South America? (Except for some small islands.)
That's insane. Does the Sun sets at 10PM?
> That's insane. Does the Sun sets at 10PM?
Umm, in Southern Europe, in summer, you get around 10 days or so where the sun sets at around 10 PM. It's great. I actually enjoy it.
Umm, in Southern Europe, in summer, you get around 10 days or so where the sun sets at around 10 PM. It's great. I actually enjoy it.
How do you fix the computers? It must take a long time to roll out changes for the computer code to deal with this
On Debian, and most *nixes I believe, the update consists of a single file. All applications read from this file.
This kind of thing is why it's important to store user-specified future dates as local time + IANA zone name.
If a user wants a calendar event at 9am, they probably still mean 9am after accounting for time zone or DST changes.
Storing dates as UTC is appropriate for dates in the past, or future dates that a user will never expect to happen at a certain wall-clock time.
(An IANA zone name is something like America/New_York, and not EST or UTC-05:00)
If a user wants a calendar event at 9am, they probably still mean 9am after accounting for time zone or DST changes.
Storing dates as UTC is appropriate for dates in the past, or future dates that a user will never expect to happen at a certain wall-clock time.
(An IANA zone name is something like America/New_York, and not EST or UTC-05:00)
It’s one heuristic, but you can’t know what they want, the problem is underspecified. It’s reasonably likely they could want a reminder to watch a game that is being broadcast from a different time zone, or call a friend in a different country.
The user interface can be akward, but you can ask them for the timezone of the event. If it's for a live event in another place, they would ideally put in the local time in the other place and the timezone there.
Or if it's a fixed time, not to be moved by DST changes anywhere, they could specify it in UTC.
It's also a good idea to calculate and save the offset when editing. Then, if the offset changes later, you can notify the user. Hey, this appointment is affected by DST change, when do you want it to be?
Or if it's a fixed time, not to be moved by DST changes anywhere, they could specify it in UTC.
It's also a good idea to calculate and save the offset when editing. Then, if the offset changes later, you can notify the user. Hey, this appointment is affected by DST change, when do you want it to be?
There should also be a way to say "my current local time, whatever that may be", such as for events reflecting a personal daily routine for exercise, medicines, etc. This should adjust accordingly as the person changes time zone instead of staying at a fixed UTC offset.
that's "floating time" and is definitely a valid option too, although for uses with multiple devices, now they've all got to agree on which timezone the user is currently subject to if you want a consistent experience.
I can’t even get employees at the company where I work to understand and communicate EDT instead of EST. I don’t think calendaring tools are going to have much success asking people what timezone they want.
I've mostly given up being pedantic about the difference between PT, PDT, and PST. Most people mean "PT" when talking about the time that work meetings are scheduled, but they say "PST" basically year-round, despite it being PDT more often than PST.
Yet if we're encouraging people to select a timezone manually (context for this particular thread) it matters, because software is (usually) happy to do exactly what you tell it to do.
Mainly, though, it just annoys me: precision sans accuracy is bloody annoying.
Mainly, though, it just annoys me: precision sans accuracy is bloody annoying.
It's not a pedantic difference; if you calculate the time as PST when it's PDT or vice versa you'll be an hour off. Holding a meeting an hour early or attending it an hour late can have serious consequences.
One way to look at pedantry is that it's when someone emphasizes technical correctness, even when another person's actual intent is understood.
If it's the middle of July, and someone in California sets up a meeting with someone in New York, but tells them "9am PST", it would be understood to actually mean "PT" or "PDT". I suspect only certain kinds of neurodivergent people would show up for the meeting an hour off. And hopefully someone who genuinely thought PST was the intention would ask for clarification. Most people, though, who would bring it up do so just for reasons of pedantry, not because they're actually confused.
If it's the middle of July, and someone in California sets up a meeting with someone in New York, but tells them "9am PST", it would be understood to actually mean "PT" or "PDT". I suspect only certain kinds of neurodivergent people would show up for the meeting an hour off. And hopefully someone who genuinely thought PST was the intention would ask for clarification. Most people, though, who would bring it up do so just for reasons of pedantry, not because they're actually confused.
This is really the same kind of reasoning as "most people know how tall five feet is" or "most people know that 'wicked' is a compliment" or "most people know that 0.59¢ per minute really means 59¢ per minute". It's obnoxious, back-slapping ethnocentrism masquerading as common sense.
Most people don't know how tall five feet is, because they use the metric system, and they don't even speak English. Most people in California and New York know those things, and they're also likely to know that you don't really mean "PST" if you're talking about a date when California is on daylight time.
But most people don't know those things, and so if what you say is the opposite of what you mean, you can expect them to be confused when they look up the definition. If that's what you're shooting for, then by all means, go right ahead. But if you're trying for clear communication, you might want to get a little bit clearer about the kinds of things "most people" know and the kinds of things most people actually know.
Daylight savings time transitions cause me scheduling grief on a regular basis, not because I'm "neurodivergent" but just because I don't know what dates Belgium or California or Chile does their stupid clock changes, because I don't live there, and they all do them on separate dates.
Most people don't know how tall five feet is, because they use the metric system, and they don't even speak English. Most people in California and New York know those things, and they're also likely to know that you don't really mean "PST" if you're talking about a date when California is on daylight time.
But most people don't know those things, and so if what you say is the opposite of what you mean, you can expect them to be confused when they look up the definition. If that's what you're shooting for, then by all means, go right ahead. But if you're trying for clear communication, you might want to get a little bit clearer about the kinds of things "most people" know and the kinds of things most people actually know.
Daylight savings time transitions cause me scheduling grief on a regular basis, not because I'm "neurodivergent" but just because I don't know what dates Belgium or California or Chile does their stupid clock changes, because I don't live there, and they all do them on separate dates.
As mentioned in https://news.ycombinator.com/item?id=32860778, timezone confusion led Scott Aaronson to miss an important meeting just today. The problem is real. (But no word on whether the cause was a daylight-time/standard-time mixup.)
Neurodivergent people, or people who aren't in California, which is actually more than 99% of people, and who therefore have to look up the timezone offset somehow.
It's probably true that the <1% of people you hang out with most of the time can correct the error without even thinking about it because they live in California too. But that doesn't make it a pedantic error; it's an error that regularly has serious consequences, precisely because people's actual intent is misunderstood.
It's probably true that the <1% of people you hang out with most of the time can correct the error without even thinking about it because they live in California too. But that doesn't make it a pedantic error; it's an error that regularly has serious consequences, precisely because people's actual intent is misunderstood.
It is a pedantic difference. While it's technically incorrect to say PST when it's currently PDT, it doesn't inhibit communication. Both parties will understand it to be that "we meeting at 9am, whenever that happens to be for our California staff" as opposed to "we are meeting at 9am PST, even though no one is currently on PST"
Even my colleague in Arizona is able to follow this despite them not joining the daylight savings time.
Technically incorrect but in a way that doesn't inhibit understanding is the definition of pedantic.
Even my colleague in Arizona is able to follow this despite them not joining the daylight savings time.
Technically incorrect but in a way that doesn't inhibit understanding is the definition of pedantic.
Fyi we ran into an actual real life example of this being a real problem since Arizona doesn't do daylight savings time it can cause miscommunication and people can miss meetings if you put the wrong S vs D. It's even worse when you consider some countries switch over at different times from S to D.
Edit
Sorry I missed the Arizona part of your comment but there are rare occasions where it can mislead people.
Yeah, I do think it's worth getting right. For the most part even those that know better but there is significant meaning there. I suspect it mostly wasn't a problem for our AZ person because the company essentially operated out of Chicago time, so in his case it was the difference between discussed times being 1 or 2 hours off.
I was just being pedantic about it being pedantic .
I was just being pedantic about it being pedantic .
When someone sets up a meeting with me in a different time zone I'll google "what time is it in [timezone]?" then calculate the difference with my timezone and apply that the day of the meeting.
If they have a DST transition between when you google and the meeting, you'll be off by an hour with that technique.
OP is calling it pedantic because most people mean PT. When someone says 9am they mean 9am regardless of the timezone, they’ll add the timezone if they’re talking with someone from a different timezone but still 99% of the time they mean 9am in their own timezone so if they’re in a region that observes dst even if they said pst they really meant pdt and you’re being pedantic by correcting them.
It's pedantic in the same sense that specifying 02022 rather than 2022 for the current year is.
In normal everyday usage, most of the time, people will understand by context and convention what is meant by "5:30" even without specifying AM or PM, let alone the timezone or TZDATA version associated. Yes, there are times specificity matters, and thinking about that can be goos, but the social frictions imposed may exceed any other benefits achieved, at least much of the time. At the same time, even where those ambiguities exist it's typically mentally jarring for people to be constantly reminded of this, even where they should be.
Where there's an opportunity for ambiguity, yes, nail down specifically what is meant. I read delecti's comment in that context, and note that they're describing themselves as the pedant. Which I interpret as "a stickler for accuracy and precision".
In normal everyday usage, most of the time, people will understand by context and convention what is meant by "5:30" even without specifying AM or PM, let alone the timezone or TZDATA version associated. Yes, there are times specificity matters, and thinking about that can be goos, but the social frictions imposed may exceed any other benefits achieved, at least much of the time. At the same time, even where those ambiguities exist it's typically mentally jarring for people to be constantly reminded of this, even where they should be.
Where there's an opportunity for ambiguity, yes, nail down specifically what is meant. I read delecti's comment in that context, and note that they're describing themselves as the pedant. Which I interpret as "a stickler for accuracy and precision".
I agree that it's an important difference, but being insistent about it is excessive because functionally those kind of mistakes just don't happen when scheduling meetings in Outlook, which is the context where it matters.
Most of my work meetings only involve people in the same city, so there's no confusion there, and thus no scheduling problems. And 99% of the rest of my meetings are with people in Europe, and the relative difference between PST and CET is the same as the relative difference between PDT and CEST (though I do have to remind people twice a year that the two time zones change to/from DST a week or two apart).
Most of my work meetings only involve people in the same city, so there's no confusion there, and thus no scheduling problems. And 99% of the rest of my meetings are with people in Europe, and the relative difference between PST and CET is the same as the relative difference between PDT and CEST (though I do have to remind people twice a year that the two time zones change to/from DST a week or two apart).
The stock calendar app on my Android phone (running LineageOS, so not sure how "stock" it really is) has a quite prominent time zone field when setting the time for an event, and I do use it quite a lot.
My experience with Google Calendar, iCal and Outlook is that they do default to the meeting creators TimeZone.
Which is often what we want!
So on that regard, I find calendar invites rather than a causal email invite to be essential.
Which is often what we want!
So on that regard, I find calendar invites rather than a causal email invite to be essential.
Yes, many tz-related difficulties indeed arise from the future uncertainty and UX complexity to deal with that uncertainty. A conscious decision would be required and can't be easily delegated to someone else.
A lot of this could be solved by inferring the time zone by location of the appointment. If you know the event occurs in a specific place at a specific time, you almost certainly want it to be the standard time zone of that place. If that place uses DST, I couldn’t think of any reason to ignore it and opt for standard time regardless.
Bonus: geopolitics change country lines, and that affects time zones as well. When the time zone at the appointment location changes due to border conflicts, you can get the new time zone without having to change anything.
Bonus: geopolitics change country lines, and that affects time zones as well. When the time zone at the appointment location changes due to border conflicts, you can get the new time zone without having to change anything.
That works if you know the location of the appointment. But if you're going to a bar to watch a televised game with friends, the location in the appointment is probably the bar, but the timezone is wherever the game is held. If you're going to have a conference call and you have a shared calendar system, great everybody should agree; if all the participants have separate calendar systems, maybe you discuss the time to have the call and each enter it in your local time, which works fine until someone's government adjusts local time on short notice. Having separate appointments sounds fragile, but have you had a good experience with cross domain calendaring? I certainly haven't.
Never mind, if you had a fully booked schedule collaborating across timezones and someone's government adjusts local time, now you've got a mess.
Never mind, if you had a fully booked schedule collaborating across timezones and someone's government adjusts local time, now you've got a mess.
But this is one more reason to save the timezone and stop calculating on current data?
Save the time and timezone of the event in the other country, so literally the time it starts not the calculated local time.
Unless the other country decides to switch timezones, well then you are screwed.
Save the time and timezone of the event in the other country, so literally the time it starts not the calculated local time.
Unless the other country decides to switch timezones, well then you are screwed.
That assumes you know what timezone the user intended. If I read somewhere that some football match in Chile is happening on November 1st at 1 o'clock, I may well put in a reminder for November 1st at 1 o'clock, without specifying a timezone or location. The calendar/reminder app would of course be unable to notify me that Chile's time for November 1st has changed, since I never told it anything about Chile.
What exactly do you expect it to do? Asking the user for the location of the event for time zone purposes might be confusing but there’s no better option.
The more common option is not to do that, and accept that in the rare cases of a timezone change, there's nothing you can do from software.
Either way, the only completely fool-proof way to make sure you never return the wrong time is to ask not for a timezone, but for GPS coordinates, and preferably some extra cultural information - since the timezone of a particular location may change completely, and that change may only be recognized by certain entities.
For example, when Russia annexed Crimeea, they could have changed the timezone (I believe they didn't, but they could have), but more nationalistic Ukrainians in Crimeea would have probably not recognized the timezone change. So, if someone had set an event for some time in the future and chose Ukraine's timezone, they may not have gotten the right reminder if the event was public (so presumably forced by Russian authorities to respect the new timezone), since you couldn't know they meant to watch something in Crimeea.
To be clear, I'm arguing it's not worth trying to solve this problem in a fool-proof way in software, not that I expect software to help in situations like the above.
Either way, the only completely fool-proof way to make sure you never return the wrong time is to ask not for a timezone, but for GPS coordinates, and preferably some extra cultural information - since the timezone of a particular location may change completely, and that change may only be recognized by certain entities.
For example, when Russia annexed Crimeea, they could have changed the timezone (I believe they didn't, but they could have), but more nationalistic Ukrainians in Crimeea would have probably not recognized the timezone change. So, if someone had set an event for some time in the future and chose Ukraine's timezone, they may not have gotten the right reminder if the event was public (so presumably forced by Russian authorities to respect the new timezone), since you couldn't know they meant to watch something in Crimeea.
To be clear, I'm arguing it's not worth trying to solve this problem in a fool-proof way in software, not that I expect software to help in situations like the above.
Then isn't the appropriate solution to store the time for that time zone?
Better still, just store dates as ISO-8601 standard YYYY-MM-DD format. Mucking about with timezones at all inevitably introduces bugs when you're just talking about dates.
Of course, times sometimes do need timezones. But calendar dates (like Christmas, or your birthday) almost never do and having things automagically do adjustments based on that and give the wrong results is just a pain.
That's one thing I don't like about many standard libraries. They'll have a DateTime object that does all kinds of automagic stuff for you (or against you), but no concept of just a date itself. Many bugs occur between 2300 and 0100 due to that (and sometimes between 1100 and 1300 because people try to compensate for the buggy adjustments by setting the unwanted time component to noon).
Another problem arises when the server's timezone is set to X, the database's timezone is Y, the software's timezone is Z, and one user's entering data in timezone A while another is reading it in timezone B - and all of the software parts along the way are each trying to automagically adjust it. A good reason we should just all switch to UTC and drop the idea of timezones entirely.
Of course, times sometimes do need timezones. But calendar dates (like Christmas, or your birthday) almost never do and having things automagically do adjustments based on that and give the wrong results is just a pain.
That's one thing I don't like about many standard libraries. They'll have a DateTime object that does all kinds of automagic stuff for you (or against you), but no concept of just a date itself. Many bugs occur between 2300 and 0100 due to that (and sometimes between 1100 and 1300 because people try to compensate for the buggy adjustments by setting the unwanted time component to noon).
Another problem arises when the server's timezone is set to X, the database's timezone is Y, the software's timezone is Z, and one user's entering data in timezone A while another is reading it in timezone B - and all of the software parts along the way are each trying to automagically adjust it. A good reason we should just all switch to UTC and drop the idea of timezones entirely.
Agree that this is a good default, but this doesn’t solve everything. For example a meeting between people in two time zones. Typically that’s handled by picking one time zone as the primary one, but that’s always not ideal.
Also some events aren’t related to human activity and you would rather not make that adjustment. It can be tricky to know which is which.
Also some events aren’t related to human activity and you would rather not make that adjustment. It can be tricky to know which is which.
> If a user wants a calendar event at 9am, they probably still mean 9am after accounting for time zone or DST changes.
...9am of their timezone or 9am of other participants time zone ?
Countries also share a timezone, what happens when they stop ?
what if you store time in CEST but the date CEST changes into CET is different in different countries ?
...9am of their timezone or 9am of other participants time zone ?
Countries also share a timezone, what happens when they stop ?
what if you store time in CEST but the date CEST changes into CET is different in different countries ?
This is why I insist on calendar invites for all my meetings!
People easily forget that others in a meeting loop are in different time zones.
Not so bad in parts Europe or the UK, but for those of us in countries with multiple TZs like the US and Australia, it’s a persistent problem!
Especially for those junior members who are new to the group video conferencing game!
Conveying TimeZones in software is also a UX issue I’ve found! People don’t really understand LOL
People easily forget that others in a meeting loop are in different time zones.
Not so bad in parts Europe or the UK, but for those of us in countries with multiple TZs like the US and Australia, it’s a persistent problem!
Especially for those junior members who are new to the group video conferencing game!
Conveying TimeZones in software is also a UX issue I’ve found! People don’t really understand LOL
Storing datetimes as UTC is not enough for even past dates for all situations. If you need to know what local time an event happened in the past and there's more than one location your user may have resided in, you need to have stored the local time as well, since there's no reliable target you could convert that UTC to.
It's more a demonstration around why changing your wall clocks in unpredictable ways (and to a lesser extent, changing them at all) is a bad idea.
Well console yourself with the fact that the current timezone arrangement is much better than the 19th C. system where every town had its own separate timezone.
When railways were introduced a multitude of local timezones made railway timetables impossible, this then led to the present system.
When railways were introduced a multitude of local timezones made railway timetables impossible, this then led to the present system.
I like keeping the offset and the zone name. Then, if there's a discrepancy, I can ask the user what to do about affected events.
Can you give a few examples of what you mean by this?
I like this chaos-monkey approach to politics, and we should do it more often.
Now let me slide this handle that increases taxes on HFT and see what happens.
Now let me slide this handle that increases taxes on HFT and see what happens.
Hell, increase tax on all trading. Most people don't need to be gambling day-to-day on equities
Your pension, sovereign wealth, ability to pay down sovereign debt for social programs, purchasing power and bank balances all depend on growth that is at a higher rate than inflation. This requires portfolio rebalancing, and investing all that fiat currency collected in taxes and other means in productive assets. To say that trading requires higher taxes is like seeing an 18 wheel transport truck shipping food and thinking that it would be more equitable if you took off some of its wheels. Robbing financial firms "because that's where the money is," is as net-economically productive and at the same level of parochial banditry as seizing truck tires. There may be a fundamental economic principle that being stupid is expensive, and thinking governments have a revenue problem should at least give one pause.
Most people don't need to be running most businesses, but it still hurts them if those businesses become less efficient.
Even better, let's lock everyone at their homes with 3 hour notice at 2 AM...
This is not novel. Look through the tzdb news and you will find many instances of similar and considerably shorter periods of notice.
Just to pick a couple from last year that are unambiguous and well-documented (most you’ll have at least a bit more trouble finding first-party announcement of):
2021d: Fiji gave a month’s notice on suspending DST for the season.
2021b: Samoa gave less than a week’s notice on cancelling DST.
I have a feeling there was a less-than-two-days’ notice a few years ago, but can’t be bothered hunting for it. But there are many more of things like “eh, we’re shifting the start or end by a day or two or a week or two, with less than ten days’ notice”.
Just to pick a couple from last year that are unambiguous and well-documented (most you’ll have at least a bit more trouble finding first-party announcement of):
2021d: Fiji gave a month’s notice on suspending DST for the season.
2021b: Samoa gave less than a week’s notice on cancelling DST.
I have a feeling there was a less-than-two-days’ notice a few years ago, but can’t be bothered hunting for it. But there are many more of things like “eh, we’re shifting the start or end by a day or two or a week or two, with less than ten days’ notice”.
I was tangentially affected by Pakistan deciding to extend DST in 2008 with very little notice. It was originally going to end on August 31, but I believe they decided on August 28 or so to extend it to October.
https://en.m.wikipedia.org/wiki/Daylight_saving_time_in_Paki...
https://www.worldtimezone.com/dst_news/dst_news_pakistan02.h...
https://en.m.wikipedia.org/wiki/Daylight_saving_time_in_Paki...
https://www.worldtimezone.com/dst_news/dst_news_pakistan02.h...
Samoa also famously skipped the 2011-12-30.
Maybe "famously among software developers" is more on-point.
Maybe "famously among software developers" is more on-point.
Was this to move to the other side of the dateline or something?
Yes.
The time change, officially decided in June, is meant to align Samoa with its Asian trading partners; it moves the islands’ work days further from the United States, which dominated its economy in the past. [0]
[0]: https://web.archive.org/web/20220809080548/https://www.nytim...
The time change, officially decided in June, is meant to align Samoa with its Asian trading partners; it moves the islands’ work days further from the United States, which dominated its economy in the past. [0]
[0]: https://web.archive.org/web/20220809080548/https://www.nytim...
Israel used to have the switch data determined by a parliamentary vote, and changed almost every year. Depending on the political power distribution, the date was moved back and forth. I don't remember the exact details already, but it was related to Jewish holidays, which involved morning prayers, so sometimes it was more convenient for certain people to move the time scale back or forward, and since Jewish holidays are celebrated following Jewish calendar, which moves around relatively to Western calendar, and since sometimes religious parties had enough power to get special consideration and sometimes they didn't...
You can look at the result e.g. here: https://git.launchpad.net/pytz/tree/tz/asia (look for "Zion" there). They thankfully finally stopped doing it in 2013 and arrived at a stable rule, but until then you can image how much confusion it caused.
You can look at the result e.g. here: https://git.launchpad.net/pytz/tree/tz/asia (look for "Zion" there). They thankfully finally stopped doing it in 2013 and arrived at a stable rule, but until then you can image how much confusion it caused.
This seemingly almost happened a year or two ago in Georgia (the US state, not the country) when the legislature overwhelmingly supported ending the twice a year time change. But much like the public, the legislature couldn't agree on if they should go to year around standard time or year around daylight saving time, with one house passing standard time overwhelmingly and the other house passing DST overwhelmingly. There's no good reason for the two houses to each have such strong affinities to one system or the other, which makes me think the two houses may have had an agreement to look like they tried to address the issue that the public wants settled once and for all without actually passing something that would make half the state upset no matter which way they went. Or the party whips in both houses are simply very effective in gaining consensus in their own chamber.
IIRC, one of the bills was to go into effect the year it was passed, which would have been extremely short notice for the IT world to deal with.
IIRC, one of the bills was to go into effect the year it was passed, which would have been extremely short notice for the IT world to deal with.
Not exactly what happened in the end. The house and senate in Georgia agreed on DST. However we can’t change to permanent DST yet. By Federal Law an act of Congress has to happen to change the law.
https://www.fox5atlanta.com/weather/permanent-daylight-savin...
https://www.fox5atlanta.com/weather/permanent-daylight-savin...
Why is an Act of Congress necessary for a State to select its timezone and DST? Arizona has been ignoring DST for many, many years now. It didn't need Congress's permission to do that, AFAIK. And in Indiana, it's county-by-county, so you can change timezones many times, back and forth, just driving across the state.
It's the same for California as well
WA, OR, and CA have all passed state laws to stay on DST. Waiting on federal govt to allow it.
Oh, CA actually did pass it? I thought it was still pending, and WA and OR were waiting on us. Did a quick search, and I don't see anything more recent than this past April, when it was not yet fully passed.
There's also the federal-level Sunshine Protection Act[0], which the Senate has passed, but annoyingly the House put it on hold back in March right after receiving it, and hasn't acted on it. Lame.
[0] https://www.congress.gov/bill/117th-congress/senate-bill/623...
There's also the federal-level Sunshine Protection Act[0], which the Senate has passed, but annoyingly the House put it on hold back in March right after receiving it, and hasn't acted on it. Lame.
[0] https://www.congress.gov/bill/117th-congress/senate-bill/623...
There was a time in the early 2000's when Indiana had three or more different time zones in the summer. In the winter the state was on eastern standard time except for three or four counties in the northwest part of the state that were on central standard time to sync with Chicago.
But in the summer there were counties that went on daylight time and others that did not. I had an important meeting with my startup in the Indianapolis area to discuss a partnership. I checked Wikipedia to find that Indianapolis was on daylight savings time. Since this guy was five miles outside Indianapolis I assumed he would be on the same time as well.
The end result was we arrived an hour early for the meeting. The guy was not pleased at all. He wasn't able to understand how I wasn't aware that he was over a county line that made all the difference in the world what time he was on. After all everyone in Indianapolis could tell you which counties used daylight time and which did not.
But it wasn't on the web and he didn't make a point of telling me. The meeting ended up going well but I left wondering how often this happened. Eventually the level of confusion resulted in Indiana moving the entire state to daylight savings time.
Guess I shouldn't be surprised. Michigan voters rejected daylight savings time twice at the polls. The state legislators finally voted to move everyone over. When there was a ballot initiative to reject what the legislature did the legislators fought it. The result was the state supreme court kept it off the ballot. But to be fair never at any time was the state on more than a single time zone.
But in the summer there were counties that went on daylight time and others that did not. I had an important meeting with my startup in the Indianapolis area to discuss a partnership. I checked Wikipedia to find that Indianapolis was on daylight savings time. Since this guy was five miles outside Indianapolis I assumed he would be on the same time as well.
The end result was we arrived an hour early for the meeting. The guy was not pleased at all. He wasn't able to understand how I wasn't aware that he was over a county line that made all the difference in the world what time he was on. After all everyone in Indianapolis could tell you which counties used daylight time and which did not.
But it wasn't on the web and he didn't make a point of telling me. The meeting ended up going well but I left wondering how often this happened. Eventually the level of confusion resulted in Indiana moving the entire state to daylight savings time.
Guess I shouldn't be surprised. Michigan voters rejected daylight savings time twice at the polls. The state legislators finally voted to move everyone over. When there was a ballot initiative to reject what the legislature did the legislators fought it. The result was the state supreme court kept it off the ballot. But to be fair never at any time was the state on more than a single time zone.
I grew up in southern Indiana, across the bridge from Louisville, Kentucky. When I was a kid my parents would setup meetings with people and they’d ask if the time was in “fast time” or “slow time”. We’d also have to switch the times in our TV guides—ET in the summer, CT in the winter.
Then Indiana decided to observe daylight savings times and we had to start running around and changing our clocks.
I wish we’d just pass a federal law that does away with the time change.
Then Indiana decided to observe daylight savings times and we had to start running around and changing our clocks.
I wish we’d just pass a federal law that does away with the time change.
Similar story for me. I went to college at Auburn, which is located in eastern Alabama about 20 miles from the Eastern/Central timezone border. Half of our broadcast TV stations came from both Columbus, Georgia (Eastern) and the other half from Montgomery, Alabama (Central). You had to remember which station you were watching and where it was from whenever a time was listed.
You don't need to be aware or guess time zones, just specify UTC offset and it becomes unambiguous to everyone around the globe.
Why not just specify in Unixtime? Definitely no confusion then!
Here is Microsoft's interim guidance for the change
<https://techcommunity.microsoft.com/t5/daylight-saving-time-...>
In my experience MSFT does a stellar job within the limits of what's possible to accommodate TZ/DST changes.
As per the TZ Info mailing list, the change was committed on 9 Aug:
<https://mm.icann.org/pipermail/tz/2022-August/031777.html>
<https://techcommunity.microsoft.com/t5/daylight-saving-time-...>
In my experience MSFT does a stellar job within the limits of what's possible to accommodate TZ/DST changes.
As per the TZ Info mailing list, the change was committed on 9 Aug:
<https://mm.icann.org/pipermail/tz/2022-August/031777.html>
In my previous job we had to deal with sudden DST changes in Jordan, Russia, Turkey... it's amazing politicians don't realize what a big deal sudden changes can be.
Edit it appears the switch was delayed due to the constitutional referendum. Turkey had national exams as a reason, I believe.
Edit it appears the switch was delayed due to the constitutional referendum. Turkey had national exams as a reason, I believe.
I would love to read a blog post from you on this topic!
Thanks, maybe I'll try to put one together!
Western Australia had a three year daylight saving trial imposed on us with short notice back around 1999. A decade later it was still dangerous to try to sync a calendar through iCloud from a Mac to a PC running Outlook. And I discovered a couple of years ago that Yealink VOIP phone still get the time wrong here during summer.
Oh man, so that's why?? I remember working on an issue for a client in Perth where their calendar was out of sync by an hour, and yep it was iCloud connected to Outlook on Windows. Being based in Victoria, I had never heard of WA's flirt with daylight savings time, but that totally explains the gremlins I was seeing.
Since we all carry veritable supercomputers with GPS in our pockets now, it's the perfect time for everybody to switch [back] to true solar time. Your noon is when the Sun is precisely at its zenith where you are.
Zones are for interoperation.
Seriously though, everyone having slightly different individual times could be real confusing.
For example, two people, a couple of hundred miles/kilometres apart share a phone call, one of them asks: "What time is the game on?"
Also, I am picturing the engineer who work on Google Maps crying at the time adjustments required for traveling east/west on the journey time/arrival time estimate.
Seriously though, everyone having slightly different individual times could be real confusing.
For example, two people, a couple of hundred miles/kilometres apart share a phone call, one of them asks: "What time is the game on?"
Also, I am picturing the engineer who work on Google Maps crying at the time adjustments required for traveling east/west on the journey time/arrival time estimate.
And it'd be confusing for public transport, too – the District Line in London already has about two minutes difference between its eastern and western termini, and thanks to the extension to Reading Crossrail manages roughly five minutes.
(And of course railways were the initial reasons we switched away from truly local solar time in the first place.)
(And of course railways were the initial reasons we switched away from truly local solar time in the first place.)
The differences in true solar time between people living in different parts of the city will be slight enough to simply ignore, no conversions needed. Other sources of error, like traffic, easily dominate the matter. If you're trying to meet up with somebody local, it works the same as it always has.
For the google maps engineer, the matter is not so complicated. Given a geo coordinate and UTC time (within 1 second of mean solar time at the prime meridian, which is good enough), they can call into a standard routine to derive the true local time at that time and place, and display that time to the user.
> "What time is the game on?"
"Computer, what time is 6pm in Denver?"
"6pm in Denver is 8:26pm for you."
For the google maps engineer, the matter is not so complicated. Given a geo coordinate and UTC time (within 1 second of mean solar time at the prime meridian, which is good enough), they can call into a standard routine to derive the true local time at that time and place, and display that time to the user.
> "What time is the game on?"
"Computer, what time is 6pm in Denver?"
"6pm in Denver is 8:26pm for you."
You are not wrong about the differences being minor for most people in a city day to day and the solutions being achievable. And it is fun to think of the challenges and possibilities of doing it another way. :-)
While for many the google maps dilemma in a city won't matter, there are always "edge cases" that google people would have to cover. I occasionally ask google maps for a 8 hour day drive. In my case, most north-south so not an issue, but for other people it could be.
And maybe not using google maps: trains, planes, trucks - logistics in general - all want to be precisely on time while covering large distances. So I think this is not as easily waved aside as a societal problem if this "midday where you are" approach was taken.
This clearly would require a fundamental change in mindset for the whole populace - so not an option we'd see coming soon! But maybe fun for a sci-fi setting.
In the end though, if you accept the cost of the sun being not quite overhead at "midday", a time zone obviates the need for further solutions. Simpler all round.
While for many the google maps dilemma in a city won't matter, there are always "edge cases" that google people would have to cover. I occasionally ask google maps for a 8 hour day drive. In my case, most north-south so not an issue, but for other people it could be.
And maybe not using google maps: trains, planes, trucks - logistics in general - all want to be precisely on time while covering large distances. So I think this is not as easily waved aside as a societal problem if this "midday where you are" approach was taken.
This clearly would require a fundamental change in mindset for the whole populace - so not an option we'd see coming soon! But maybe fun for a sci-fi setting.
In the end though, if you accept the cost of the sun being not quite overhead at "midday", a time zone obviates the need for further solutions. Simpler all round.
Game time would just depend on the location (and timezone) for the stadium.
Interim guidance from Microsoft [1]
>Microsoft plans to release an update to support this change; however, there may be insufficient time to properly build, test, and release such an update before the change goes into effect. In the meantime, we recommend that organizations with devices in the Republic of Chile temporarily disable automatic DST adjustments in Windows to reflect the correct local time between September 4, 2022 and September 11, 2022.
[1] https://techcommunity.microsoft.com/t5/daylight-saving-time-...
>Microsoft plans to release an update to support this change; however, there may be insufficient time to properly build, test, and release such an update before the change goes into effect. In the meantime, we recommend that organizations with devices in the Republic of Chile temporarily disable automatic DST adjustments in Windows to reflect the correct local time between September 4, 2022 and September 11, 2022.
[1] https://techcommunity.microsoft.com/t5/daylight-saving-time-...
Speaking of, are we supposed to be doing anything about this yet, or should we just wait til 30 days before?
https://www.congress.gov/bill/117th-congress/senate-bill/623
My assumption is that it'll eventually get revived in the House sometime next year, but they will -- correctly -- decide that November 2023 will be too soon after it becomes law, will change the text to specify some date in 2024, but then it'll have to go back to the Senate, where it will get held up for dumb procedural (or political) reasons, and then we'll just repeat the same thing over and over.
Italy has not yet made a decision on a whether DST will ever end this year and I suppose the situation is similar in other European countries.
I can't even imagine the chaos if each EU country makes their own choice last minute
I can't even imagine the chaos if each EU country makes their own choice last minute
I don't think they can do that on their own, can they? There's still an EU wide rule on DST. They never revoked it, AFAIK.
In 2018, the European Parliament voted to get rid of twice a year clock changes. It came after a poll of 4.6 million EU citizens showed strong support for scrapping it.
I'm not sure however what's the process of getting this actually implemented.
I'm not sure however what's the process of getting this actually implemented.
I believe it is up to the current (always rotating) President of the Council of the European Union to raise / implement / pass it on to some other instance.
https://european-union.europa.eu/institutions-law-budget/ins...
Correct me if Im wrong. Its really hard to understand how EU works, even for us on the inside.
https://european-union.europa.eu/institutions-law-budget/ins...
Correct me if Im wrong. Its really hard to understand how EU works, even for us on the inside.
> It came after a poll of 4.6 million EU citizens showed strong support for scrapping it.
A poll where something like 2/3rds of the responses came from Germany (where somehow that topic had become a particularly hot issue), even though it only accounted for approximately 1/6th of the EU population pre-Brexit.
A poll where something like 2/3rds of the responses came from Germany (where somehow that topic had become a particularly hot issue), even though it only accounted for approximately 1/6th of the EU population pre-Brexit.
For context that's a bit over 1% of the total 447 million people who live in the EU
And it wasn't widely known. I think it was mainly Germans. I would have voted against it.
Me too. I still find it hard to talk to friends and family members who just don't seem to get it that the sun will rise one hour later, i.e. that kids will have to go to school before sunrise in december/january where I live . The discussion around DST always happens during summer when people feel sad about it ending and the looming prospect of shortening days, most noticeable when the clocks get back to non-DST time.
EU countries disregard EU rules all the time
Well, news regarding the plebiscite ate up any attempt to talk about the time change issue.
To clarify, this has been a constant from 2011. We jumped from a well defined schedule on March/October, to May/August, to DST all year round, to a new timezone for people down south, to the new April/September schedule… interrumpted by the plebiscite.
And well, "commissions" are always on the works to a definite schedule once and for all; but…
(BTW, for the person who said there are cities in lower longitudes than Punta Arenas: yes, but think of a country that goes from Tallinn [Estonia] to the south border of Egypt)
To clarify, this has been a constant from 2011. We jumped from a well defined schedule on March/October, to May/August, to DST all year round, to a new timezone for people down south, to the new April/September schedule… interrumpted by the plebiscite.
And well, "commissions" are always on the works to a definite schedule once and for all; but…
(BTW, for the person who said there are cities in lower longitudes than Punta Arenas: yes, but think of a country that goes from Tallinn [Estonia] to the south border of Egypt)
This also happened in Egypt in 2016, but it was only 3 days notice..
https://www.washingtonpost.com/news/worldviews/wp/2016/07/06...
> Media doesn't seem to be reporting much on this
This seems like a perfect example of something mostly local. I wouldn't expect US or other news to cover it, it just won't generate revenue for them.
This seems like a perfect example of something mostly local. I wouldn't expect US or other news to cover it, it just won't generate revenue for them.
I guess the government were upset that the new constitution didn't pass, so they thought, "well we have to cause chaos somehow!"
Honestly, time zones should be abolished. We should live with the same synchronized 24 hour clock everywhere.
Man, Algeria changed the weekend (from saturday+sunday to friday+saturday) on a two day notice.
This is why I personally want everything to just be utc without timezones
Well... https://qntm.org/abolish
Time zones are fine. Random time zone offset changes are not.
Time zones are fine. Random time zone offset changes are not.
"Random time zone offset changes are not."
Are you saying that our computer systems are so inflexible that we cannot make them do our bidding? The issue here has nothing to do with whether daylight saving is appropriate or not, rather it's about the inability of computers to adapt quickly.
When I was studying computing I had a textbook titled Problems for Computer Solution, it was about how to get computers to do our bidding - not vice versa!
Are you saying that our computer systems are so inflexible that we cannot make them do our bidding? The issue here has nothing to do with whether daylight saving is appropriate or not, rather it's about the inability of computers to adapt quickly.
When I was studying computing I had a textbook titled Problems for Computer Solution, it was about how to get computers to do our bidding - not vice versa!
"Are you saying that our computer systems are so inflexible that we cannot make them do our bidding? "
Yes, of course that is the case. Any non-internet connected clock (microwaves, cars, toys, $10 alarm clocks, wristwatches, etc) will not be able to respond to these types of changes.
Calling these computers may be significantly overstating their abilities.
"it was about how to get computers to do our bidding - not vice versa"
It's much easier to declare that problems ought not exist, than to actually solve them in a practical, global manner.
In many cases, the owner of the device also isn't aware of the change. This is not a problem specific to software.
Yes, of course that is the case. Any non-internet connected clock (microwaves, cars, toys, $10 alarm clocks, wristwatches, etc) will not be able to respond to these types of changes.
Calling these computers may be significantly overstating their abilities.
"it was about how to get computers to do our bidding - not vice versa"
It's much easier to declare that problems ought not exist, than to actually solve them in a practical, global manner.
In many cases, the owner of the device also isn't aware of the change. This is not a problem specific to software.
"Any non-internet connected clock (microwaves, cars, toys, $10 alarm clocks, wristwatches, etc) will not be able to respond to these types of changes."
My post about 19th C. timezones and train timetables is about this very point. All these independent systems are independent 'timezones' and that's the problem - and it's a fundamental one!
First, closed systems are intrinsically subject to drift and will never really be on time anyway. Second, there's nothing wrong with an independent closed system having a 'clock' - 'oscillator' would be a better word here - but it was all too convenient to couple this with external time systems. In essence, independent closed systems will never be in sync with external time.
If closed systems have to have time clocks that are an analog of real-world time then they should always be considered an approximation as with all analog systems. Relying on them for accuracy has to be a last ditch resort.
The trouble is that we never adopted this newer mindset from the outset of digital systems, instead we simply repeated the earlier mistake of every town having its own timezone.
There are ways around these problems just as there were in the 19th C. but no one has bothered to implement them.
This is not the place to delve into them except to say that they involve both technological solutions and an automatic assumption by humans that closed systems cannot be relied upon to provide accurate time.
My post about 19th C. timezones and train timetables is about this very point. All these independent systems are independent 'timezones' and that's the problem - and it's a fundamental one!
First, closed systems are intrinsically subject to drift and will never really be on time anyway. Second, there's nothing wrong with an independent closed system having a 'clock' - 'oscillator' would be a better word here - but it was all too convenient to couple this with external time systems. In essence, independent closed systems will never be in sync with external time.
If closed systems have to have time clocks that are an analog of real-world time then they should always be considered an approximation as with all analog systems. Relying on them for accuracy has to be a last ditch resort.
The trouble is that we never adopted this newer mindset from the outset of digital systems, instead we simply repeated the earlier mistake of every town having its own timezone.
There are ways around these problems just as there were in the 19th C. but no one has bothered to implement them.
This is not the place to delve into them except to say that they involve both technological solutions and an automatic assumption by humans that closed systems cannot be relied upon to provide accurate time.
I think you're mixing up a few different causes and concepts.
Wristwatches are generally accurate and can generally be relied upon. It's not practical or reasonable to say they should be a "last ditch resort" simply because they do not handle legislative corner cases.
All clocks are approximations to some degree, because time and space are relative. This is true of all systems of measurement in science, in general.
It's not possible to have a computer perfectly account for all legislative corner cases for the same reason it's not possible to have a perfect map: Grey areas exist within law and geopolitics. Knowing the time requires knowing map boundaries and which authority controls a given area. For example: Does Ukraine observe DST? The Donbass region?
Furthermore there are practical costs associated with automatic clocks: A GPS, an updating map system and an updating database of time legislation is expensive to implement in terms of hardware, energy, etc.
These are not problems that no one's bothered to implement. They come at a cost which we aren't willing to shoulder, or in some cases are intractably complex social questions with simple pragmatic work-arounds (make the clock dumb and set it to whatever you wish)
In reality, close enough is often good enough. Perfection isn't necessary.
Wristwatches are generally accurate and can generally be relied upon. It's not practical or reasonable to say they should be a "last ditch resort" simply because they do not handle legislative corner cases.
All clocks are approximations to some degree, because time and space are relative. This is true of all systems of measurement in science, in general.
It's not possible to have a computer perfectly account for all legislative corner cases for the same reason it's not possible to have a perfect map: Grey areas exist within law and geopolitics. Knowing the time requires knowing map boundaries and which authority controls a given area. For example: Does Ukraine observe DST? The Donbass region?
Furthermore there are practical costs associated with automatic clocks: A GPS, an updating map system and an updating database of time legislation is expensive to implement in terms of hardware, energy, etc.
These are not problems that no one's bothered to implement. They come at a cost which we aren't willing to shoulder, or in some cases are intractably complex social questions with simple pragmatic work-arounds (make the clock dumb and set it to whatever you wish)
In reality, close enough is often good enough. Perfection isn't necessary.
"It's not practical or reasonable to say they should be a "last ditch resort" simply because they do not handle legislative corner cases."
I essentially agree with this comment and most of what you've said. No doubt, in hindsight, I could have expressed the matter more clearly and succinctly.
What I should have stressed is that there should be a greater emphasis placed on the formal aspects of the problem (as opposed to day-to-day practicalities).
If from a computer science perspective we had a more clearly defined formalism in respect of time then programmers would be much more careful about time ambiguities and separating internal clock mechanisms from external ones.
I've not given this huge thought but if say computer languages had declarative statements and underlying mechanisms to separate internal and external clocks then some of these problems may be averted. This perhaps could be extended further by having any number of 'clock subsystems' and having a formal mechanism that defines (and or couples) the relationships between them.
If languages made these distinctions in clear, non ambiguous ways then they'd always be at the forefront of programmers' minds even if on most occasions those relationships were set to 1:1.
If one thinks about it this isn't as a preposterous idea as it may seem as the whole notion of relative time naturally falls out of Relativity/Spacetime.
Making computers and compter languages inherently aware of the fact would likely bring benefits. This, no doubt, would add upfront complexity but the payoff would come when dealing with problems of the type we've been discussing here.
I essentially agree with this comment and most of what you've said. No doubt, in hindsight, I could have expressed the matter more clearly and succinctly.
What I should have stressed is that there should be a greater emphasis placed on the formal aspects of the problem (as opposed to day-to-day practicalities).
If from a computer science perspective we had a more clearly defined formalism in respect of time then programmers would be much more careful about time ambiguities and separating internal clock mechanisms from external ones.
I've not given this huge thought but if say computer languages had declarative statements and underlying mechanisms to separate internal and external clocks then some of these problems may be averted. This perhaps could be extended further by having any number of 'clock subsystems' and having a formal mechanism that defines (and or couples) the relationships between them.
If languages made these distinctions in clear, non ambiguous ways then they'd always be at the forefront of programmers' minds even if on most occasions those relationships were set to 1:1.
If one thinks about it this isn't as a preposterous idea as it may seem as the whole notion of relative time naturally falls out of Relativity/Spacetime.
Making computers and compter languages inherently aware of the fact would likely bring benefits. This, no doubt, would add upfront complexity but the payoff would come when dealing with problems of the type we've been discussing here.
"if say computer languages had declarative statements and underlying mechanisms to separate internal and external clocks"
Well, we actually do have those things. You're pretty much describing how the unix time APIs work today.
The internal unix clock is kept as a "time_t", "struct timeval", or "struct timespec", which is seconds, usec, or nsec since an epoch. This is largely insulated from the geopolitical nonsense -- though it is imperfect with respect to leap seconds and it should have been defined as TAI. This is specified in sys/time.h on linux . These are further separated into clocks like CLOCK_REALTIME and CLOCK_MONOTONIC, which track adjusted actual time (updated by ntp), and elapsed relative time respectively.
The "external clocks" as you call them are specified by the time.h functions like "ctime" or "localtime." These functions take the above internal clocks and apply timezone data to localize time to a specific area on earth.
"If one thinks about it this isn't as a preposterous idea as it may seem as the whole notion of relative time naturally falls out of Relativity/Spacetime."
Right, but we do this already. There's no such thing as a clock without a frame of reference though, so there will always be some special location in space/time which is the perspective of the system clock.
"Making computers and compter languages inherently aware of the fact would likely bring benefits. "
We already have reaped these benefits! The existing problems center around stuff like:
* Figuring out who's a correct relative authority for a given place on earth
* Communicating updates (and, correspondingly, guarding against bad updates)
* Figuring out how to keep various autonomous systems consistent
* Helping software developers understand these inherent complexities in timekeeping -- because I guarantee your average software developer is largely unaware that all these distinctions already exist.
Well, we actually do have those things. You're pretty much describing how the unix time APIs work today.
The internal unix clock is kept as a "time_t", "struct timeval", or "struct timespec", which is seconds, usec, or nsec since an epoch. This is largely insulated from the geopolitical nonsense -- though it is imperfect with respect to leap seconds and it should have been defined as TAI. This is specified in sys/time.h on linux . These are further separated into clocks like CLOCK_REALTIME and CLOCK_MONOTONIC, which track adjusted actual time (updated by ntp), and elapsed relative time respectively.
The "external clocks" as you call them are specified by the time.h functions like "ctime" or "localtime." These functions take the above internal clocks and apply timezone data to localize time to a specific area on earth.
"If one thinks about it this isn't as a preposterous idea as it may seem as the whole notion of relative time naturally falls out of Relativity/Spacetime."
Right, but we do this already. There's no such thing as a clock without a frame of reference though, so there will always be some special location in space/time which is the perspective of the system clock.
"Making computers and compter languages inherently aware of the fact would likely bring benefits. "
We already have reaped these benefits! The existing problems center around stuff like:
* Figuring out who's a correct relative authority for a given place on earth
* Communicating updates (and, correspondingly, guarding against bad updates)
* Figuring out how to keep various autonomous systems consistent
* Helping software developers understand these inherent complexities in timekeeping -- because I guarantee your average software developer is largely unaware that all these distinctions already exist.
Right, I'm not disagreeing with any of that except to say it's application is not ubiquitous and thus not universally applied despite the fact that it's part of a common O/S.
If it were then the DST problem would not have arisen or that it would have been much easier and qicker to solve. (That is, not every one understands the issue to the point where it's no longer the subject of debate - ipso facto, the fact that we're having this debate on HN demonstrates that lack of universality.)
A similar system with a niche application which also possesses truly advanced relativistic timekeeping features is the software for GPS satellites. However it too hasn't been universally applied (needless to say, it'd also likely require extensive modification if it were to be adapted for the use that we're discussing here, that said, no doubt the basic algorithms would be adaptable).
If it were then the DST problem would not have arisen or that it would have been much easier and qicker to solve. (That is, not every one understands the issue to the point where it's no longer the subject of debate - ipso facto, the fact that we're having this debate on HN demonstrates that lack of universality.)
A similar system with a niche application which also possesses truly advanced relativistic timekeeping features is the software for GPS satellites. However it too hasn't been universally applied (needless to say, it'd also likely require extensive modification if it were to be adapted for the use that we're discussing here, that said, no doubt the basic algorithms would be adaptable).
No, these systems are universally applied. You pretty much can't find software which doesn't use the abstractions I describe above. They're baked into every major framework.
The DST problem is due to the database that these interfaces use not being designed for rapid updates.
The DST problem is due to the database that these interfaces use not being designed for rapid updates.
It would be indeed great if our computer systems could adapt to those changes quickly. But the reality is that they can't, and there are many excuses available; for example there are many devices which are not continuously connected to the global network but can still keep a clock ticking. Jurisdictions are expected to take account of this reality, no matter you like it or not.
Most computers adapt just fine. International travel and cooperation are the real problem, especially in our increasingly globalized world.
We live on an approximately spherical world, its rotation is not tidal locked to its star, its rotational axis is not perpendicular to its orbital plane, we evolved to synchronize our biological rhythms including our sleep/wake cycle to local sunrise and sunset, we occupy a wide range of latitudes and longitudes, and we need to coordinate activities with people who are far away from us.
Switching to worldwide UTC doesn't change any of that, and you end up needing to add something that is essentially equivalent to timezones.
Switching to worldwide UTC doesn't change any of that, and you end up needing to add something that is essentially equivalent to timezones.
Not really. It only changes the numbers on a clock. Whether the clock says 1900 or 2300 doesn't inherently need to relate to anything about the rotational axis or sunrise/sunset, latitude, astrological readings of the zodiac, etc.
Furthermore, it'd be much easier to coordinate activities with people who are far away from us if you could just say 2300 and they'll know when that is because it's the exact same time for them on their clock. Timezones are what makes that bad in the first place!
This idea that we for some reason need to keep changing and tinkering with the labels on the clocks due to flaky political reasons is just a silly old superstitious tradition. Just pick one timezone and let's all use it already.
In fact, you can already see how well that can work if you live away from the equator. As the year progresses, the days get shorter and longer day by day - but we don't adjust the clocks by a couple of minutes every single day. Because it doesn't matter whether the clock labels match up with the sunlight.
If it did in fact matter, then we'd need special clocks that sometimes run faster during daylight and sometimes slower, depending on latitude and date so that we get the same number of 'minutes' of daylight at the same 'times' each day even though the actual lengths and times vary. But we don't do that of course both because it would be totally nonsensical, and also because it doesn't matter.
Furthermore, it'd be much easier to coordinate activities with people who are far away from us if you could just say 2300 and they'll know when that is because it's the exact same time for them on their clock. Timezones are what makes that bad in the first place!
This idea that we for some reason need to keep changing and tinkering with the labels on the clocks due to flaky political reasons is just a silly old superstitious tradition. Just pick one timezone and let's all use it already.
In fact, you can already see how well that can work if you live away from the equator. As the year progresses, the days get shorter and longer day by day - but we don't adjust the clocks by a couple of minutes every single day. Because it doesn't matter whether the clock labels match up with the sunlight.
If it did in fact matter, then we'd need special clocks that sometimes run faster during daylight and sometimes slower, depending on latitude and date so that we get the same number of 'minutes' of daylight at the same 'times' each day even though the actual lengths and times vary. But we don't do that of course both because it would be totally nonsensical, and also because it doesn't matter.
> Furthermore, it'd be much easier to coordinate activities with people who are far away from us if you could just say 2300 and they'll know when that is because it's the exact same time for them on their clock.
Whoever picks 2300 for the coordinated activity still usually needs to know how far east/west the other parties are from them in order to pick a time that they all will be awake, which generally means a time that is during the daytime in their locations, and for many activities also should be a time during normal business hours in each person's location.
Their normal business hours will generally be shifted about one hour for every 15° longitude difference. People will generally prefer normal business hours in a given area to be the same to make it easier to coordinate local events.
And so we still end up with zones based on longitude where within the zone business hours and other periodic daily things are coordinated to fall at the same time, and those times are shifted from those in the adjacent zones.
Whoever picks 2300 for the coordinated activity still usually needs to know how far east/west the other parties are from them in order to pick a time that they all will be awake, which generally means a time that is during the daytime in their locations, and for many activities also should be a time during normal business hours in each person's location.
Their normal business hours will generally be shifted about one hour for every 15° longitude difference. People will generally prefer normal business hours in a given area to be the same to make it easier to coordinate local events.
And so we still end up with zones based on longitude where within the zone business hours and other periodic daily things are coordinated to fall at the same time, and those times are shifted from those in the adjacent zones.
Additionally, either the calendar day boundary is tied to 00:00 new-UTC, which would be incredibly awkward for everybody not living near wherever the meridian ends up (which invariable will be a large fraction of the world's population, no matter which meridian you end up choosing), because now all of a sudden the calendar day changes in the middle of everybody's waking hours (public holidays starting and stopping at e.g. 2 o'clock in the afternoon anyone?), or else each location needs to offset the calendar date change by some suitable value so it ends up roughly were it used to be (i.e. at a time when most people sleep), which again means basically re-introducing time zones through the back door.
No doubt changing daylight saving rules at short notice is difficult but we should be asking ourselves why is it so.
The major problem adjusting to daylight saving should be as it's always been - that of human adaptation to the sudden change of time. That our computers cannot adapt at a moment's notice simply says there's fundamental problem with their design.
Moreover, the problem should have been long solved by now. Remember the huge kerfuffle over the Y2k problem 22 years ago? You'd think we'd have learned from that and fixed the problem back then.
Either we're lazy or slow learners or both.
The major problem adjusting to daylight saving should be as it's always been - that of human adaptation to the sudden change of time. That our computers cannot adapt at a moment's notice simply says there's fundamental problem with their design.
Moreover, the problem should have been long solved by now. Remember the huge kerfuffle over the Y2k problem 22 years ago? You'd think we'd have learned from that and fixed the problem back then.
Either we're lazy or slow learners or both.
Far more coordination with this than something like Y2K. This is a government deciding the rules of time have changed in some way. Y2K, the rules of time didn't change, but a pattern of implementation decisions frequently used over the previous few decades broke down.
A system that needs to know about the rule change has to actually receive it in some way. It has to be connected or the update has to be brought to it. That alone creates a lot of systems that cannot react to a change like this at a moment's notice.
You know when Y2K and Y2038 hit relative to yourself because they're numerical rollovers that can be computed from your current time. You can't know when the congress of Whereveralia has decided to change DST rules without someone or something telling you.
A system that needs to know about the rule change has to actually receive it in some way. It has to be connected or the update has to be brought to it. That alone creates a lot of systems that cannot react to a change like this at a moment's notice.
You know when Y2K and Y2038 hit relative to yourself because they're numerical rollovers that can be computed from your current time. You can't know when the congress of Whereveralia has decided to change DST rules without someone or something telling you.
The fundamental problem is that we humans are slaves to our computer systems instead of them being our slaves. By definition, a computer is a streamlined process or procedure designed to help humans but that's so often not the case. (Something that's so often overlooked.)
The fact is that the biggest problem in computing is that their ergonomics suck big-time. This daylight saving issue is yet another instance of it.
Seems to me that both hardware designers and programmers should have a course in ergonomics as a prerequisite before they embark on their profession.
I say that as someone who has literally lost years off my life trying to get poorly designed computers to adapt to doing the simplest of tasks.
The fact is that the biggest problem in computing is that their ergonomics suck big-time. This daylight saving issue is yet another instance of it.
Seems to me that both hardware designers and programmers should have a course in ergonomics as a prerequisite before they embark on their profession.
I say that as someone who has literally lost years off my life trying to get poorly designed computers to adapt to doing the simplest of tasks.
No, the fundamental problem is that DST is an ill-conceived concept, and being forced to inscribe it in software exposes all the contradictions and inconsistencies.
As another poster said, when is 1:30am on November 6th in Ontario?
The only thing this has to with computers is that we do all organizational stuff with computers nowadays. Changing DST on short notice would have caused chaos in the 19th century as well.
As another poster said, when is 1:30am on November 6th in Ontario?
The only thing this has to with computers is that we do all organizational stuff with computers nowadays. Changing DST on short notice would have caused chaos in the 19th century as well.
"an ill-conceived concept,"
That's just an opinion, not an absolute fact. There's nothing fundamental about it. After all, over the last hundred years or more most countries have had DST so that's the opposite opinion - and for DST to be so widely adopted many millions thought it was a good idea.
I'm only stating facts. Frankly, I couldn't give damn whether we had DST or not and I can never understand why people get so hot and bothered over the issue.
If I were ever forced to choose a system then I'd choose neither standard time or DST. Instead I'd move all clocks forward an hour and leave them there permanently but I'd never lose any sleep over the matter.
That's just an opinion, not an absolute fact. There's nothing fundamental about it. After all, over the last hundred years or more most countries have had DST so that's the opposite opinion - and for DST to be so widely adopted many millions thought it was a good idea.
I'm only stating facts. Frankly, I couldn't give damn whether we had DST or not and I can never understand why people get so hot and bothered over the issue.
If I were ever forced to choose a system then I'd choose neither standard time or DST. Instead I'd move all clocks forward an hour and leave them there permanently but I'd never lose any sleep over the matter.
I literally lose sleep twice a year over DST :D
Yes, twice. When the clock suddenly moves back, that also causes jetlag.
Yes, twice. When the clock suddenly moves back, that also causes jetlag.
No doubt that's a significant problem for you and others like you.
But then how do we reconcile your requirements with those of others, especially when their requirements differ significantly from yours?
The usual answer is to base this on a democratic decision. Either way, the minority loses out.
On that point, my comments to this story turned out to be provocative but that definitely wasn't my original intention. Nevertheless, what has been very informative has been the voting on my comments, they've oscillated continually but on average they've ended up pretty close to neutral.
This tells me that strongly opposing views are held in relatively equal numbers across the population and other surveys seem to indicate this depending on country, location etc. That said, the opponents of DST seem to be making a stronger pushing politically at the moment (fashions change, where I am DST was overwhelming supported when first introduced and it still has relatively strong support although its opponents are more vocal nowadays).
As a person who doesn't care one way or other, it seems I'm part of a rather small minority.
But then how do we reconcile your requirements with those of others, especially when their requirements differ significantly from yours?
The usual answer is to base this on a democratic decision. Either way, the minority loses out.
On that point, my comments to this story turned out to be provocative but that definitely wasn't my original intention. Nevertheless, what has been very informative has been the voting on my comments, they've oscillated continually but on average they've ended up pretty close to neutral.
This tells me that strongly opposing views are held in relatively equal numbers across the population and other surveys seem to indicate this depending on country, location etc. That said, the opponents of DST seem to be making a stronger pushing politically at the moment (fashions change, where I am DST was overwhelming supported when first introduced and it still has relatively strong support although its opponents are more vocal nowadays).
As a person who doesn't care one way or other, it seems I'm part of a rather small minority.
That's a nice rant, and I don't entirely disagree with you, but it has little to do with my comment.
Politics can change faster than the time it takes to lick a postage stamp and can do so in the most unpredictable ways. That's been a fact of life for the whole of human existence.
That said, a processor can do billions of operations in the time it takes to lick a stamp. Thus, there's plenty of leeway there to ensure that computers don't even enter the political equation.
That said, a processor can do billions of operations in the time it takes to lick a stamp. Thus, there's plenty of leeway there to ensure that computers don't even enter the political equation.
My point is that ergonomics and design is secondary to connectivity (continuous, intermittent, sneakernet, whatever) for a great deal of systems that need to care about time, including the latest political whims regarding time.
The fastest processor ever created can't do anything with information it doesn't have.
The fastest processor ever created can't do anything with information it doesn't have.
"...with information it doesn't have."
That's my point. But when it eventually gets that info it shouldn't be impeded in updating as is the present system.
That's my point. But when it eventually gets that info it shouldn't be impeded in updating as is the present system.
I think that the problem is that DST is a really, really bad idea.
So you have a process that starts at 1:30am on November 6, 2022.
If that's in Ontario, is that the first 1:30am or the second one? (At 2:00am, clocks go back to 1:00am, so we do that hour again.
If the process is supposed to start at 2:30am on March 12, 2023, that's too bad, because at 2:00am the time jumps to 3:00am, so no times from 2:00am to 2:59:59am are valid.
And now some regions are abandoning DST and others aren't. I'm not sure if it's still the case, but in Indiana one part of the state was on Central Time and another part on Eastern Time, and both observed DST. There was a third part that was on Central Time but did not observe DST, so part of the year it would match Central Time and the rest of the year it matched Eastern Time (IIRC).
So you have a process that starts at 1:30am on November 6, 2022.
If that's in Ontario, is that the first 1:30am or the second one? (At 2:00am, clocks go back to 1:00am, so we do that hour again.
If the process is supposed to start at 2:30am on March 12, 2023, that's too bad, because at 2:00am the time jumps to 3:00am, so no times from 2:00am to 2:59:59am are valid.
And now some regions are abandoning DST and others aren't. I'm not sure if it's still the case, but in Indiana one part of the state was on Central Time and another part on Eastern Time, and both observed DST. There was a third part that was on Central Time but did not observe DST, so part of the year it would match Central Time and the rest of the year it matched Eastern Time (IIRC).
Starting in 2006, the entire state of Indiana uses DST.
It's an issue everywhere you rely on data that's not purely static, but evolving too slowly to treat it as dynamic.
The Y2K problem was entirely preventable in comparison. Timezones will keep changing erratically.
The Y2K problem was entirely preventable in comparison. Timezones will keep changing erratically.
In my opinion it’s because it’s so easy to assume a day has 24 hours. Coding for an occasional day that has 23 and another with 25 just doesn’t occur to most people.
Yeah, like so. But these changes aren't just 'one-offs', they're in fact common enough for a streamlined procedure to be in place - yet it's not.
Some call it "chaos", others might call it "badly written software".
A lot of the time it's not really a matter of how well or badly the code has been written. It's more that an app hasn't been deployed in a long time and the infrastructure has changed, so now you have to update the deploy process. Or that the people who worked on it have moved on and now there's no understanding of the functionality, or documentation, so running a QA check is hard. Or that the test suite has broken so you need to fix that first. Or even that you don't know which systems rely on dates so you have to audit everything.
Code quality doesn't help if things are coded in inflexible ways, but there is so much more to ops in a big company.
Code quality doesn't help if things are coded in inflexible ways, but there is so much more to ops in a big company.
If that's the case then let this be a wake-up call because there will be a time when you need to update your application in less than a week (see log4j for an example).
On 2022-08-15, IANA released their third zoneinfo database of 2022. On 2022-03-15, the IANA timezone database changed for the state of Palestine as they decided to move from DST a day later after going to DST a day earlier in 2021-10-29, which was also announced just over a week before the change.
If this is the third time this year your company has been in panic mode because of sudden timezone changes, you should really be changing your processes. Timezone databases change multiple times a year!
On 2022-08-15, IANA released their third zoneinfo database of 2022. On 2022-03-15, the IANA timezone database changed for the state of Palestine as they decided to move from DST a day later after going to DST a day earlier in 2021-10-29, which was also announced just over a week before the change.
If this is the third time this year your company has been in panic mode because of sudden timezone changes, you should really be changing your processes. Timezone databases change multiple times a year!
Some might call it "chaos", others might call it "stupid government policy compounded by (the expected) moronic government implantation guidelines"
This time there was a good reason for postponing the switch. Originally it would have been the same day of the constitutional referendum. It was a good call to remove one potential factor of chaos from that day.
Having to deal with online calendars being off by one hour for a week is not that bad in comparison, we are already used to that :)
Having to deal with online calendars being off by one hour for a week is not that bad in comparison, we are already used to that :)
The latter is too wordy. "chaos" suffices!
This is why I dislike custom "we'll-do-it-ourselves" solutions. Updating your operating system's tz-database is easy; it's normally a single package with no dependencies that you can install without patching the rest of your outdated operating system full of security holes if you're in an "enterprise" environment where normal updates are seemingly impossible.
If you need to rebuild your application or even your Docker container (just bind-mount it in place and update the host, all applications fixed in one go!) then IMO you're bringing this kind of crap on yourself.
At most you should be reloading/restarting your application to apply the new timezone database, which shouldn't cause a problem if you've set up the right fallback and scaling systems to deliver whatever SLA you've promised to customers.
My shitty PHP frontends I built when I finished high school can update and reload the timezone database in less than a second through `systemctl restart php8.1-fpm`. If you need a month to update the timezone database, maybe you should've written whatever you made in shitty PHP just like me, because apparently shitty PHP is more foolproof in handling common occurrences like timezone changes than Enterprise Grade (TM) Cloud (R) Applications (C).
If you need to rebuild your application or even your Docker container (just bind-mount it in place and update the host, all applications fixed in one go!) then IMO you're bringing this kind of crap on yourself.
At most you should be reloading/restarting your application to apply the new timezone database, which shouldn't cause a problem if you've set up the right fallback and scaling systems to deliver whatever SLA you've promised to customers.
My shitty PHP frontends I built when I finished high school can update and reload the timezone database in less than a second through `systemctl restart php8.1-fpm`. If you need a month to update the timezone database, maybe you should've written whatever you made in shitty PHP just like me, because apparently shitty PHP is more foolproof in handling common occurrences like timezone changes than Enterprise Grade (TM) Cloud (R) Applications (C).
Your post is completely missing the point. Here are some examples of what I have seen go wrong:
* Microsoft didn't release an update, all Windows machines had incorrect time.
* Google Calender never got the update, it was wrong for a week. Shifting everything by one hour in your head isn't too bad but for some reason meetings scheduled by people in other timezones weren't off by an hour.
* Slack never got the update
* Managed databases running on cloud providers didn't get the update.
* A default Postgres installation will run with the tzdata shipped with Postgres, the next release is 1-2 months away. Some distros probably use the OS tzdata instead and you could recompile to fix this.
* Software using temporary credentials and MFA systems broke because timestamps mismatched.
Unless you run your whole company on homegrown code you would surely feel some pain if something like this happened in your country.
* Microsoft didn't release an update, all Windows machines had incorrect time.
* Google Calender never got the update, it was wrong for a week. Shifting everything by one hour in your head isn't too bad but for some reason meetings scheduled by people in other timezones weren't off by an hour.
* Slack never got the update
* Managed databases running on cloud providers didn't get the update.
* A default Postgres installation will run with the tzdata shipped with Postgres, the next release is 1-2 months away. Some distros probably use the OS tzdata instead and you could recompile to fix this.
* Software using temporary credentials and MFA systems broke because timestamps mismatched.
Unless you run your whole company on homegrown code you would surely feel some pain if something like this happened in your country.
I'm sure I would, because many services I use daily are in fact written badly. I don't exactly expect much from tech giants like Microsoft and Google as they get localisation and feature detection wrong all the time if you're not living in the USA. As for Slack, I'm glad I use that minimally.
Managed databases not getting the patch are badly managed. Postgres deciding to do its own thing because it thinks it knows better is a bad decision if it doesn't know better. They've decided, probably for good reason, that the OS zoneinfo wasn't good enough, but that places the burden of maintaining zoneinfo files on them.
Temporary credentials and MFA should not be timezone dependent at all, if the difference in timezones between client and server are a problem then the software hasn't been designed right.
I'm not saying nobody will notice timezone changes and the bugs they cause; of course people do, because commonly used software tends to be written badly. That doesn't mean the responsibility of fixing this crap doesn't fall on the people writing software.
The real world moves fast sometimes and timezones are complicated; to fix that, either rely on someone else who's maintaining this stuff for you (distro packagers etc.) or take responsibility for your own solution. My shitty PHP code deals with the timezone change without issue by restarting the daemon process every other day at a random point in time; the fact these billion dollar tech giants can't work out a solution is a symptom of a much bigger problem to me. The FAANG people earning ridiculous amounts of money each month should be smart enough to figure out how do deploy a zonefile update in a day or two.
Managed databases not getting the patch are badly managed. Postgres deciding to do its own thing because it thinks it knows better is a bad decision if it doesn't know better. They've decided, probably for good reason, that the OS zoneinfo wasn't good enough, but that places the burden of maintaining zoneinfo files on them.
Temporary credentials and MFA should not be timezone dependent at all, if the difference in timezones between client and server are a problem then the software hasn't been designed right.
I'm not saying nobody will notice timezone changes and the bugs they cause; of course people do, because commonly used software tends to be written badly. That doesn't mean the responsibility of fixing this crap doesn't fall on the people writing software.
The real world moves fast sometimes and timezones are complicated; to fix that, either rely on someone else who's maintaining this stuff for you (distro packagers etc.) or take responsibility for your own solution. My shitty PHP code deals with the timezone change without issue by restarting the daemon process every other day at a random point in time; the fact these billion dollar tech giants can't work out a solution is a symptom of a much bigger problem to me. The FAANG people earning ridiculous amounts of money each month should be smart enough to figure out how do deploy a zonefile update in a day or two.
Not all, or most, software that deals with time can be updated and deployed with less than 30 days notice. This is simply a grotesquely impractical policy change.
A lot of chaos has resulted, at least according to Reddit [1], which is where I found out about it.
Media doesn't seem to be reporting much on this, the most I've been able to find is one article from before the changeover [2] and a changelog for the IANA tzdb [3].
[1] https://old.reddit.com/r/talesfromtechsupport/comments/x9kr4...
[2] https://www.theregister.com/2022/09/07/microsoft_windows_chi...
[3] https://data.iana.org/time-zones/tzdb/NEWS