4 ms·

Interesting that they only announced it six days in advance. That doesn’t really give software vendors time to release zoneinfo updates.

starphase 5y ago
Fiji has a habit of changing DST at the last minute, so people have to do the low-tech solution. https://www.fbcnews.com.fj/news/fijians-reminded-to-switch-off-automatic-mode-on-devices/ https://www.fbcnews.com.fj/news/fijians-reminded-to-switch-o... However before software vendors can release zoneinfo updates, someone needs to inform the maintainers of tzdata, and they need to make a release. At least in this case someone appears to have done that already. This does cause problems though. Any software that makes dates in the future (calendar software, billing systems) runs into issues if the future date changes.
- andrewfong 5y ago
  > At least in this case someone appears to have done that already. Where do you see this?
  - starphase 5y ago
    https://mm.icann.org/pipermail/tz/2021-September/030397.html https://mm.icann.org/pipermail/tz/2021-September/030397.html The release is the thing that still needs to happen, but that is close to.
gerikson 5y ago
I have personally been involved in fallout from last-minute changes to DST in * Jordan * Russia * Armenia * Turkey Morocco suspends DST during Ramadan. Because legally you cannot predict the start and end of Ramadan (it's determined by direct observation) this is quite the challenge to handle.
- signal11 5y ago
  For people wondering why Morocco has DST (which isn’t that useful for countries relatively close to the equator?), it seems Morocco chose to permanently become UTC+1 in 2018, with the exception of Ramadan, when it’s UTC. So it’s not really DST in the summer months as done in Europe. Although the Moroccan approach makes for an interesting technical challenge!
  - shagie 5y ago
    Searching for Ramadan in https://github.com/eggert/tz/blob/main/asia https://github.com/eggert/tz/blob/main/asia and https://github.com/eggert/tz/blob/main/africa https://github.com/eggert/tz/blob/main/africa is an interesting read. Morocco textual history is at https://github.com/eggert/tz/blob/main/africa#L628 https://github.com/eggert/tz/blob/main/africa#L628 and the implementation rules are at https://github.com/eggert/tz/blob/main/africa#L903 https://github.com/eggert/tz/blob/main/africa#L903 Just above that is this bit: # From Paul Eggert (2020-05-31): # For now, guess that in the future Morocco will fall back at 03:00 # the last Sunday before Ramadan, and spring forward at 02:00 the # first Sunday after two days after Ramadan. To implement this, # transition dates and times for 2019 through 2087 were determined by # running the following program under GNU Emacs 26.3. (This algorithm # also produces the correct transition dates for 2016 through 2018, # though the times differ due to Morocco's time zone change in 2018.) # (let ((islamic-year 1440)) # (require 'cal-islam) # (while (< islamic-year 1511) # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year))) # (b (+ 2 (calendar-islamic-to-absolute (list 10 1 islamic-year)))) # (sunday 0)) # (while (/= sunday (mod (setq a (1- a)) 7))) # (while (/= sunday (mod b 7)) # (setq b (1+ b))) # (setq a (calendar-gregorian-from-absolute a)) # (setq b (calendar-gregorian-from-absolute b)) # (insert # (format # (concat "Rule\tMorocco\t%d\tonly\t-\t%s\t%2d\t 3:00\t-1:00\t-\n" # "Rule\tMorocco\t%d\tonly\t-\t%s\t%2d\t 2:00\t0\t-\n") # (car (cdr (cdr a))) (calendar-month-name (car a) t) (car (cdr a)) # (car (cdr (cdr b))) (calendar-month-name (car b) t) (car (cdr b))))) # (setq islamic-year (+ 1 islamic-year))))
    - 5y ago
lifthrasiir 5y ago
And that triggered another unrelated problem because there has been a controversial change to merge several timezones that are alike since 1970 (the current tzdb has been inconsistent about them) and the Samoan change has triggered the next release (2021b) so the debate has to be somehow settled before that release.
JoeAltmaier 5y ago
Hm? Back in 2005 I made a zoneinfo push feature in handheld scanners for a big manufacturer. The only delay in updating, should be bureaucratic.
oefrha 5y ago
Unfortunately the IANA tzdb is less reliable than most developers would probably assume. A few years ago I was using moment-timezone for a web app and noticed it was displaying time wrong for Chinese users. Looking into the issue, I found out that the packaged tzdb version somehow thought China Standard Time was observing DST, which was a brief experiment scrapped decades ago. Digging into tzdb source, I felt like being thrown into an old style wiki page where people argue with each other back and force over the years, leaving all the historical arguments directly in comments in the source code. At times people just go with incomplete information and somewhat questionable sources, which might get corrected a decade later. You can check for yourself: https://data.iana.org/time-zones/tzdb-2021a/asia https://data.iana.org/time-zones/tzdb-2021a/asia (Btw, I can't really pinpoint the problematic version I encountered years ago now.)

starphase 5y ago

Fiji has a habit of changing DST at the last minute, so people have to do the low-tech solution. https://www.fbcnews.com.fj/news/fijians-reminded-to-switch-off-automatic-mode-on-devices/ https://www.fbcnews.com.fj/news/fijians-reminded-to-switch-o... However before software vendors can release zoneinfo updates, someone needs to inform the maintainers of tzdata, and they need to make a release. At least in this case someone appears to have done that already. This does cause problems though. Any software that makes dates in the future (calendar software, billing systems) runs into issues if the future date changes.

andrewfong 5y ago
> At least in this case someone appears to have done that already. Where do you see this?
- starphase 5y ago
  https://mm.icann.org/pipermail/tz/2021-September/030397.html https://mm.icann.org/pipermail/tz/2021-September/030397.html The release is the thing that still needs to happen, but that is close to.

gerikson 5y ago

I have personally been involved in fallout from last-minute changes to DST in * Jordan * Russia * Armenia * Turkey Morocco suspends DST during Ramadan. Because legally you cannot predict the start and end of Ramadan (it's determined by direct observation) this is quite the challenge to handle.

signal11 5y ago
For people wondering why Morocco has DST (which isn’t that useful for countries relatively close to the equator?), it seems Morocco chose to permanently become UTC+1 in 2018, with the exception of Ramadan, when it’s UTC. So it’s not really DST in the summer months as done in Europe. Although the Moroccan approach makes for an interesting technical challenge!
- shagie 5y ago
  Searching for Ramadan in https://github.com/eggert/tz/blob/main/asia https://github.com/eggert/tz/blob/main/asia and https://github.com/eggert/tz/blob/main/africa https://github.com/eggert/tz/blob/main/africa is an interesting read. Morocco textual history is at https://github.com/eggert/tz/blob/main/africa#L628 https://github.com/eggert/tz/blob/main/africa#L628 and the implementation rules are at https://github.com/eggert/tz/blob/main/africa#L903 https://github.com/eggert/tz/blob/main/africa#L903 Just above that is this bit: # From Paul Eggert (2020-05-31): # For now, guess that in the future Morocco will fall back at 03:00 # the last Sunday before Ramadan, and spring forward at 02:00 the # first Sunday after two days after Ramadan. To implement this, # transition dates and times for 2019 through 2087 were determined by # running the following program under GNU Emacs 26.3. (This algorithm # also produces the correct transition dates for 2016 through 2018, # though the times differ due to Morocco's time zone change in 2018.) # (let ((islamic-year 1440)) # (require 'cal-islam) # (while (< islamic-year 1511) # (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year))) # (b (+ 2 (calendar-islamic-to-absolute (list 10 1 islamic-year)))) # (sunday 0)) # (while (/= sunday (mod (setq a (1- a)) 7))) # (while (/= sunday (mod b 7)) # (setq b (1+ b))) # (setq a (calendar-gregorian-from-absolute a)) # (setq b (calendar-gregorian-from-absolute b)) # (insert # (format # (concat "Rule\tMorocco\t%d\tonly\t-\t%s\t%2d\t 3:00\t-1:00\t-\n" # "Rule\tMorocco\t%d\tonly\t-\t%s\t%2d\t 2:00\t0\t-\n") # (car (cdr (cdr a))) (calendar-month-name (car a) t) (car (cdr a)) # (car (cdr (cdr b))) (calendar-month-name (car b) t) (car (cdr b))))) # (setq islamic-year (+ 1 islamic-year))))
  - 5y ago

lifthrasiir 5y ago

And that triggered another unrelated problem because there has been a controversial change to merge several timezones that are alike since 1970 (the current tzdb has been inconsistent about them) and the Samoan change has triggered the next release (2021b) so the debate has to be somehow settled before that release.

JoeAltmaier 5y ago

Hm? Back in 2005 I made a zoneinfo push feature in handheld scanners for a big manufacturer. The only delay in updating, should be bureaucratic.

oefrha 5y ago

Unfortunately the IANA tzdb is less reliable than most developers would probably assume. A few years ago I was using moment-timezone for a web app and noticed it was displaying time wrong for Chinese users. Looking into the issue, I found out that the packaged tzdb version somehow thought China Standard Time was observing DST, which was a brief experiment scrapped decades ago. Digging into tzdb source, I felt like being thrown into an old style wiki page where people argue with each other back and force over the years, leaving all the historical arguments directly in comments in the source code. At times people just go with incomplete information and somewhat questionable sources, which might get corrected a decade later. You can check for yourself: https://data.iana.org/time-zones/tzdb-2021a/asia https://data.iana.org/time-zones/tzdb-2021a/asia (Btw, I can't really pinpoint the problematic version I encountered years ago now.)