What happens after 2020

[dharapvj]

This just a question rather than any issue.

There are two files offered by this project.. "All years" and "2010-2020".

What I am interested is only current and future dates. so.. can I just use 2010-2020 file? What happens if I forget all about this decision and year 2021 starts? Will I start getting wrong values for DST?

Thanks in advance.

[mattjohnsonpint]

Well, even the source data changes regularly. Time zones are a political decision, and are subject to change at the whim of the world's governments. So in order to keep current, you'll need to have a plan to update regularly.

Sometimes these changes are done under very short notice as well. See my blog posts here and here for more about this, and the problems that can create.

It doesn't make a lot of sense to look to far into the future, because there's little guarantee that things won't change between now and then. Nobody can tell you whether DST will be in effect in the year 3000. Really, even the idea that we know when it will take effect next year is based on the presumption that there won't be a new law enacted before then.

The reason for the two different files is that moment-timezone's data doesn't contain the year-over-year rules, but rather contains specific transitions for a given range of years. This makes for much faster lookup at runtime, but comes at the expense of having to decide on a subset of the data to work with. The "all years" file contains all known transitions from the past, and then about 20 additional years of transitions into the future. The "2010-2020" file contains only the near past and near future. Most likely, you only need that file.

What will likely happen as this library evolves forward is that we will advance the window for that file. Next year, it will be 2011-2021. The following will be 2012-2022, etc. This assumes we stick with the current data format. Of course, it could change by then as well. :)

Either way, we'll have to continue distributing updates, and you'll have to keep applying them. The only alternative is an active approach in which we maintain a "current" data file for you to point at that always has the latest information, rather than having to update with each release. Indeed, we may do just that at some point.

[mattjohnsonpint]

Marking this as "enhancement" to remind us to create a "current data" pointer.

Another approach you could take in the meantime is to point at a CDN cached version of the data files on GitHub:

https://github.com/moment/moment-timezone/blob/master/builds/moment-timezone-with-data.min.js

https://cdn.rawgit.com/moment/moment-timezone/master/builds/moment-timezone-with-data-2010-2020.min.js

It would probably be more convenient if we changed the name to just "truncated" instead of having the years, such that the path doesn't change. I'll consider that for a future release.

[manojdcoder]

@mj1856 I was looking for a direct answer, why I need moment-timezone when I have Date.prototype. toLocaleString with timezone option. I read couple of your answers on stack overflow pointing about few bugs in Chrome / FireFox in particular time zones. Was that the only reason - Moment is more perfect than toLocaleString?

[maggiepint]

@manojdcoder ECMAScript does not support time zones other than UTC and the user's local time zone for computations. That time zone code only helps you with formatting. So what happens if you want to add three days over a DST transition that happens in Brazil when the computer is running in the US? You have to (at this time) use moment-timezone. As the ECMA 402 APIs get better support, this won't be the case. Also of note, the TZ functionality is not supported in IE or Safari, so, not sure how you are supposed to help those people without this library.

Also, please open new issues. Placing unrelated comments on old issues is not a great way to get help.

[LayZeeDK]

I'd love to know the answer to the original question:

What happens if I forget all about this decision and year xxxx starts? Will I start getting wrong values for DST?

[gunnarSensus]

I'd love to know the answer to the original question:

What happens if I forget all about this decision and year xxxx starts? Will I start getting wrong values for DST?

Yes you will get wrong values for DST. A dev who no longer works at my company imported the 2010-2020 data and then everyone promptly forgot about it and i can 100% confirm that you will get the wrong values for DST.

[LayZeeDK]

Thanks for sharing that experience, @gunnarSensus. No errors, just wrong UTC offsets?

[gunnarSensus]

yea, no errors that i noticed. we only used moment-timezone for displaying dates to the user and stored everything in epochs so everything worked as expected after updating to a version with current data.

[arstropica]

Per @gunnarSensus comment, I would hate to think what could happen if a 2010-2020 file was being used in a hospital environment or some other time-critical operation. Moment.js is a pretty well known and trusted library. It took us a while to track down the cause our incorrect daylight savings time calculation.
It might be really helpful to update the main page of this repository with a notice and information about the expired 2020 timezone data.

[slacabos]

Some build files stop at 2022. They should probably be updated to a future year.

[gilmoreorless]

There are rolling 10-year-range files that gets updated every release, and these should be used instead of any fixed year ranges. The old 2012-2022 files have had deprecation warnings added: #1035

[slacabos]

@gilmoreorless thanks!

[gilmoreorless]

Following up on this, I've published a new Guides section for the Moment Timezone documentation. Specifically, there's now a section on what happens when you calculate a date after the end of the data range: https://momentjs.com/timezone/guides/#/data-calculations/limited-range/

[LayZeeDK]

Thank you for that guide, @gilmoreorless!