Tell HN: Sudden Chile daylight savings time rules change causes chaos
The government of Chile changed the local rules for daylight savings with approximately 30 days notice.
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...
173 comments
[ 3.0 ms ] story [ 180 ms ] threadEdit it appears the switch was delayed due to the constitutional referendum. Turkey had national exams as a reason, I believe.
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 :)
Code quality doesn't help if things are coded in inflexible ways, but there is so much more to ops in a big company.
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!
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).
* 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.
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.
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.
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 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.
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.
The fastest processor ever created can't do anything 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.
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.
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.
Yes, twice. When the clock suddenly moves back, that also causes jetlag.
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.
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).
The Y2K problem was entirely preventable in comparison. Timezones will keep changing erratically.
Now let me slide this handle that increases taxes on HFT and see what happens.
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).
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.
53 degrees north puts you around Nottingham, England (or a little north of Berlin).
But Magallanes doesn't really matter, they don't have DST.
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.)
Who else would have that power, though? Every government has the power to set the time within their own borders.
https://en.wikipedia.org/wiki/Xinjiang_Time
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.
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.
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?
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.
Time zones are fine. 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!
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.
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.
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.
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.
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.
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).
The DST problem is due to the database that these interfaces use not being designed for rapid updates.
Switching to worldwide UTC doesn't change any of that, and you end up needing to add something that is essentially equivalent to timezones.
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.
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.
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”.
https://en.m.wikipedia.org/wiki/Daylight_saving_time_in_Paki...
https://www.worldtimezone.com/dst_news/dst_news_pakistan02.h...
Maybe "famously among software developers" is more on-point.
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...
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)
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?
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).
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.
I was just being pedantic about it being pedantic .
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.
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.
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.
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".
Mainly, though, it just annoys me: precision sans accuracy is bloody annoying.
Which is often what we want!
So on that regard, I find calendar invites rather than a causal email invite to be essential.
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.
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.
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.
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.
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.
When railways were introduced a multitude of local timezones made railway timetables impossible, this then led to the present system.
...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 ?
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
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.
I can't even imagine the chaos if each EU country makes their own choice last minute
I'm not sure however what's the process of getting this actually implemented.
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.
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.
"When does my flight leave?"
"At the scheduled time."
"According to what clock?"
"Huh?"
I just showed up an hour early.
The second part about arab world are not correct through. I grew up in Egypt which used to have daylight saving change but this ceased to happen from 2011 I think.
1. https://en.m.wikipedia.org/wiki/Haiti_indemnity_controversy
2. https://en.m.wikipedia.org/wiki/United_States_occupation_of_...
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.
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.
https://www.fox5atlanta.com/weather/permanent-daylight-savin...
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...
<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>
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.
>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-...
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 of course railways were the initial reasons we switched away from truly local solar time in the first place.)
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."
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.
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.
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.
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.
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)