Imminent issue for Morocco users (tzdata2020a)

[apaprocki]

ICU 66.1 only includes IANA time zone data tzdata2019c:
https://github.com/unicode-org/icu/blob/maint/maint-66/icu4c/source/data/misc/zoneinfo64.txt#L8

Upstream tzdata2020a was released to address the prior incorrect assumed temporary reversion of DST in Morocco due to Ramadan (eggert/tz@f9aacaf).

ICU merged unicode-org/icu@a951ab5 and released updated .res files for 2020a about 9 days ago. Unless the data files are manually updated and a new release is cut, users in Morocco and Intl API usage with zone Africa/Casablanca will see the time off by an hour between May 24th and May 31st.

[apaprocki]

The tz-announce mailing list announces new releases, so is a good source to monitor: https://mm.icann.org/mailman/listinfo/tz-announce

Those then have to be packaged up and released as ICU binaries:
https://unicode-org.atlassian.net/browse/ICU-21094
unicode-org/icu-data#11
https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew/2020a/44

There's usually a day (or few) lag between the two.

[srl295]

ICU won't re-release 67 including this. For this we need… actually, we need to follow the process in your PR nodejs/node#30364 :)

but that won't help full-icu: for that we probably need some kind of side-load timezone process, which I mentioned in nodejs/node#32466

[apaprocki]

actually, we need to follow the process in your PR

Yeah, I pinged @MylesBorins with this and let him know it would require that same patching approach to get it out in time.

but that won't help full-icu: for that we probably need some kind of side-load timezone process

FWIW I do that with our build of Node, using the out-of-band .res files on disk and the environment variable support to override the directory if necessary.

[codebytere]

I have a patch locally which applies changes for this issue as specified in @apaprocki's doc PR - shall i go ahead and open that?

[srl295]

Sounds good. That env var support could be documented too.

[srl295]

PR LGTM.
Edit The pull request nodejs/node#33362 looks good. Since this is an imminent issue, I wanted to give watchers here a headsup.

[BethGriggs]

We discussed this in the release meeting today (#580).

nodejs/node#33362 has now landed on master. The PR has also been cherry-picked on to v14.x-staging, ready to go out in the next v14.x release. Unfortunately, that is unlikely to happen before the 24th May (based on our current release schedule).