Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Sudden Chile daylight savings time rules change causes chaos

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 174 posts

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#31

Post by jeroenhd »

iwwr wrote: post #3

Some call it "chaos", others might call it "badly written software".

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).

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#32

Post by sjsdaiuasgdia »

hilbert42 wrote: post #23
sjsdaiuasgdia wrote: post #15

Earlier quoted context omitted.

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.…

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.…

That's a nice rant, and I don't entirely disagree with you, but it has little to do with my comment.

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#33

Post by edbaskerville »

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.

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#34

Post by hilbert42 »

grog454 wrote: post #25
spiffytech wrote: post #20

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…

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.

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#35

Post by jeroenhd »

onion2k wrote: post #8
iwwr wrote: post #3

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 s…

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!

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#36

Post by macintux »

toast0 wrote: post #26
MobiusHorizons wrote: post #22

Earlier quoted context omitted.

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…

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.

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#37

Post by gramie »

hilbert42 wrote: post #5

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…

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).

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#38

Post by hocuspocus »

hilbert42 wrote: post #5

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…

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.

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#39

Post by lifthrasiir »

hilbert42 wrote: post #27
lifthrasiir wrote: post #17

Earlier quoted context omitted.

Well... https://qntm.org/abolish 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…

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.

Re: Tell HN: Sudden Chile daylight savings time rules change causes chaos

#40

Post by hilbert42 »

sjsdaiuasgdia wrote: post #32
hilbert42 wrote: post #23

Earlier quoted context omitted.

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.…

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.

Post reply on HN