-
Notifications
You must be signed in to change notification settings - Fork 834
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEEDBACK WANTED] Proposal for 1.0.0 breaking changes #1039
Comments
1. Move
|
2. Remove the pre-built
|
3a. Change the packed data formatWhat this meansThe packed data format used by Moment Timezone is an efficient text-based encoding of the tzdb data. For the full tzdb dataset, a 12MB But it's not as efficient as it could be, which has been exposed by recent complaints about the package size (#999). The maximum efficiency would be to use a custom binary format instead of JSON, but that's unfeasible for several reasons. There are some significant gains that can be made within the current format, though — mostly by reducing a lot of repetition. The packed JSON format has changed a few times before, but they've always been additive changes that are backwards-compatible with older versions. These proposed updates aren't a massive revamp of the format, but will still change the data in a way that's incompatible with parsing in older versions. Consequences
ExamplesThe exact format changes aren't specifically defined yet, as I've only done some small experiments. However, these would be the most likely changes: Expand example snippets
- "Africa/Tunis|LMT PMT CET CEST|-E.I -9.l -10 -20|01232323232323232323232323232323232|...",
+ "Africa/Tunis|LMT PMT CET CEST|-E.I -9.l -10 -20|01{23,g}2|...", The best result I've got so far is 22% of the original JSON size (805KB -> 183KB) without any loss of data, which is even more efficient than using a generic tool such as |
3b. Restrict the maximum future data rangeWhat this meansThis is related to the data size problems detailed at #999 (comment). The main reason the data files are so large lately is that we're using the full 64-bit versions of the tzdb's However, the chances are very low that the predicted time zone data is still accurate that far in the future. World governments change their time zone rules frequently, often at short notice, which is why there are several tzdb releases every year. I propose restricting the full packaged time zone data to 100 years in the future, based on the year of release for a Moment Timezone version. All past historical data would still be included, as that is (mostly) more accurate and far less likely to change. So for example, a package release built in 2023 would include data from 1844 to 2123. I feel this is a reasonable trade-off between data accuracy and small(ish) file sizes. (The packed JSON file would drop to less than half its current size, even without compression.) This could be done in addition to compressing the data format as described above, or instead of it, depending on feedback. Consequences
|
3c. Extract data updates into separate packagesWhat this meansCurrently the In basic terms:
Honestly, I haven't fully explored all the details of this option. There are a large number of unknown questions and consequences — e.g. how do we guarantee compability between all the different code and data packages? And building/publishing releases could become far more of a burden on maintainers. My gut feel is that doing this might cause more problems than it solves, but I'm happy to be proven wrong. The changes will need to work equally well for people using Moment Timezone in the browser via CDNs, on the server via We could also maintain the 0.x release line with the old data structure for a little while, to ease the transition to the new setup. |
First of all - THANK YOU so much for stepping up to help maintain Moment and Moment-Timezone. I've mostly stepped away from this library, but I've been noticing the work you're doing and appreciate it very much! As for your proposed changes, I feel like you're the best one to make the call about what to do from here forward. I say, if you're willing to do the work and support it - then go for it. 👍 On the specific points:
Again - thanks! |
Ad. 3c (extracting data to a separate package) - I don't know |
@mgol - It's a good idea conceptually. However in practice, it requires a lot of tricks to actually implement over the current A better plan might be to build Moment and Moment-TimeZone replacements on top of TC39's Temporal proposal. One could start developing now, using their published polyfill. Eventually the proposal will reach stage 4, and start being implemented in all major JS runtimes. Then you drop the polyfill, and release. |
Hi everyone. I've recently (last year) joined the maintenance team for Moment Timezone, and I'd like to gather feedback on some proposed changes for the project. First I should clarify the current status. As stated in the primary documentation:
That said, I've been slowly going through the backlog of open issues for Moment Timezone and I've noticed some common trends:
moment-timezone
requires and modifies coremoment
causes a lot of confusion and problems with dependency management.0.x.y
semantic version numbers are not well understood, and don't make sense for such a long-running project.While keeping in mind the guidelines listed above, there's no way to fix these common problems without a breaking change.
Therefore, I'm proposing a⚠️ one-time breaking change release to move ⚠️ .
moment-timezone
to v1.0.0There are 5 potential changes that I'd like feedback on, but 3 of them are closely related so they're listed as "a", "b" and "c" variations. Each proposed change will be in a separate comment, to allow separate inline reactions (such as 👍 or 👎) on each one. If you have more detailed feedback, feel free to leave a constructive comment.
But what about "maintenance mode"?
As noted above, the Project Status section of the Moment documentation says that major changes like this will not be happening. So isn't this plan a direct contradiction of that public statement? Sort of.
The documented project status is mostly focused on the core Moment library, which is certainly more widely-used than the Moment Timezone extension. The line "We will not be making any major changes (no version 3)" is targeted at work that had been started to completely revamp Moment's internals and move to an immutable API. Moment Timezone has some slightly looser restrictions:
Ultimately, this issue is not a guarantee of change, it's a call for feedback. If there's a big pushback to some or all of the proposals, they won't be implemented. There's also no defined timeline yet, just some ideas. There's no rush on this project (I actually only agreed to join the team because the project is in maintenance mode — I get to things in my own time).
The text was updated successfully, but these errors were encountered: