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

21–30 of 174 posts

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

#21

Post by darrenf »

chrismorgan wrote: post #18

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

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

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

#22

Post by MobiusHorizons »

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

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

#23

Post by hilbert42 »

sjsdaiuasgdia wrote: post #15
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…

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.

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.

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

#24

Post by zeroonetwothree »

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…

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.

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

#25

Post by grog454 »

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.

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

#26

Post by toast0 »

MobiusHorizons wrote: post #22
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 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?

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

#27

Post by hilbert42 »

lifthrasiir wrote: post #17
Zekio wrote: post #14

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.

"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!

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

#28

Post by lifthrasiir »

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…

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.

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

#29

Post by foepys »

MobiusHorizons wrote: post #22
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 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.

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.

Post reply on HN