Interesting that they only announced it six days in advance. That doesn’t really give software vendors time to release zoneinfo updates.
* 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.
So it’s not really DST in the summer months as done in Europe.
Although the Moroccan approach makes for an interesting technical challenge!
Morocco textual history is at https://github.com/eggert/tz/blob/main/africa#L628 and the implementation rules are at 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))))This argues emacs calendar is the gold standard implementation.
I missed them being on permanent "summer time" (UTC+1) except Ramadan.
Our customers deal with contact centers and they do a lot of business with France, so this is major headache for them.
> Since the new moon is not in the same state at the same time globally, the beginning and ending dates of Ramadan depend on what lunar sightings are received in each respective location. As a result, Ramadan dates vary in different countries, but usually only by a day.
Although officially the month starts when an official sees the new moon, I wonder to what extent they predict in advance when the moon is likely to be visible and then, in order to avoid unnecessary disruption, they make sure that that is indeed when they see it.
> The OIC says religious scholars will have access to accurate pictures of the shape of the Moon instead of having to rely on naked-eye sightings which have in the past created discrepancies between Muslim countries or mistakes.
> "Hopefully the satellite will stop the problems associated with lunar sightings," spokesman Ahmed Imigene says.
> "The satellite will have a fixed camera on board that will take highly detailed pictures of the Moon and beam them back to earth," says Professor Mervat Awad, the centre's director.
> Dr Ali Juma, chief of the 15-member panel from Saudi Arabia, Egypt, the United Arab Emirates and Bahrain which decided on the contract for the satellite, says it will solve many problems related to crescent sighting.
Though... not all countries use that technology. I'm not sure if its still in use as that was 15 years ago.
He moved way up north after graduation, and I, being an inquisitive fellow, asked him how he coped with Ramadan when it occurred during the summer months (when midnight sun was a thing).
The reply was reassuringly pragmatic. -'Oh, I just follow the fast in Mecca, much simpler than for my brethren south of the Arctic Circle.'
I bet 2 VPs were trying to determine the direction for their teams.
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.
Where do you see this?
The release is the thing that still needs to happen, but that is close to.
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
(Btw, I can't really pinpoint the problematic version I encountered years ago now.)