Update to timezone database 2022b

[repl-angrez-singh]

No description provided.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: repl-angrez-singh (d8b0bd8)

[nickosepulveda]

In Chile, the time change is approaching very soon. We are waiting for the new version to install it.

[moranza]

@nickosepulveda Can the pr be merged? We would like to have the 0.5.35 version before 4.9 :)

[jasonmobley]

@ellenaua we could use your help getting this change merged and a new release published ASAP due to the DST policy change in Chile mentioned above by others.

https://www.timeanddate.com/news/time/chile-dst-delay-2022.html

[joebehymer]

Hello, we would very much appreciate this getting merged as soon as possible.

We are considering whether to copy this branch into a local fork of moment-timezone to work around this. Getting this merged will save us quite some time. Cheers.

[alexmaie]

Hi, we are affected by the timezone change in Chile which was announced two weeks ago. We can't patch our system without 2022c

[lhorie]

@alexmaie I went ahead and published an unofficial fork including 2022c here https://www.npmjs.com/package/moment-timezone-fork

[alexmaie]

@lhorie thanks for the update !!!

[ichernev]

Hey, 0.5.36 is now released (featuring 2022c tz data).

@nickosepulveda the way moment-timezone works is that you have code and you have data, and you can always provide your own (newer) data if you'd like. So next time, instead of waiting for somebody on the internet to fix things in your codebase, you can compile any data you want with grunt data:2022c (for example) and then put data/packed/latest.json somewhere accessible on your server, then fetch it, parse it and pass it to moment.tz.load(dataObject).

There is also little need to provide a fork just for an updated data file, but ... whatever floats your boat I guess.

[joebehymer]

Thank you @ichernev

Maybe we can all take this as a wake up call to migrate away from moment :)

[lhorie]

@ichernev For context, we maintain a large monorepo w/ hundreds of services owned by different teams, so loading data files via code changes and then subsequently coordinating deployments for all the services is not really feasible, especially on short notice.

If using grunt data + .tz.load(...) is the recommendation (even after considering that moment-timezone is used in server, browser and isomorphic contexts, and considering bundle size concerns), it might be a good idea to document that.

Alternatively, leveraging Intl like date-fns does might be another option, if the maintainers are still willing to make code changes of that magnitude.