Potential breaking changes in Moment Timezone data format

[gilmoreorless]

Hiya, this is a friendly heads-up. I'm planning to do a one-off breaking change release for moment-timezone at some (currently unspecified) point in the future, and I'm currently seeking feedback: moment/moment-timezone#1039

One of the potential changes is around the date range and format of the packed JSON data. My understanding is that js-joda also uses these packed JSON files — is that correct? If so, I have some questions for you:

1. Do you use the packed.json data directly, using your own parser, or do you just reuse the parsing functions in moment-timezone-utils.js?
2. Would a change to the packed data format break your project?
3. Would a change to the maximum date range in the data break your project?

A rough idea of some of the format changes is detailed in some example snippets at moment/moment-timezone#1039 (comment). I'd love to get your feedback.

[pithu]

Hello @gilmoreorless

first of all, thank you for the information. I thought moment is "legacy" and "done" and just waiting for the temporal proposal. I wonder how that fits with a major refactoring of Moment ?

1. Yes we just using packed json data at runtime as is from moment timezone project and we are generating some smaller latest-*.json variants with utils function from moment-timezone at build time [https://github.com/js-joda/js-joda/blob/main/packages/timezone/transform-data.js]
   At runtime js-joda is parsing the data by a little helper copied from moment-timezone https://github.com/js-joda/js-joda/blob/main/packages/timezone/src/unpack.js.

2. Therefore yes, changes in the packed data structure would break js-joda. But we could always generate the data from a fixed version of moment-timezone as a work around. What would be super helpful: a HowTo for generating a new packed version. I could not find anything in the moment-timezone repo.
   But switching to a new packed data format should not be difficult to implement.

3. No, js-joda can handle dates up to year 999999. But because we are using the moment-timezone data, js-joda is affected by the year 2038 issue as well. That is one of the most urgent issues.
   Beside that, we already thought about a refactoring of the data generation, because we miss the daylight saving indicator in the data, see DateTimeFormatter.ofPattern('zzz') does not include daylight/standard time indicator #518 (comment)

tldr; It would be super awesome, if there would be a new data format, that fixes the 2038 and other issues!

[pithu]

I just saw that the 2038 issue is already fixed, but introduced moment/moment-timezone#999.

So yes, fixing filesize, would be really important. Either by supplying several ranges of tzdb data (eg +-10 and +-100 years) and / or a by compacting data even more.

I like the idea of having a separate tzdb javascript package, that is feasible also for other libraries.

[gilmoreorless]

Thanks for your thoughts!

I thought moment is "legacy" and "done" and just waiting for the temporal proposal. I wonder how that fits with a major refactoring of Moment ?

This is somewhat explained in the opening part of the issue (But what about "maintenance mode"?). I'm only considering this change because:

1. It doesn't touch the core Moment library at all.
2. The changes have a fairly small surface area, and don't involve rewriting large chunks of the codebase. They're not really a major refactoring, just some small tweaks that happen to break the API contract.

That said, the potential change I'm the most hesitant about is extracting the data to one or more separate packages. I haven't properly dug into how it would work, and it might turn out to be too disruptive if a lot of the internals have to change.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 14 days.