Skip to content
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

What happens after 2020 #363

Open
dharapvj opened this issue Jul 26, 2016 · 9 comments
Open

What happens after 2020 #363

dharapvj opened this issue Jul 26, 2016 · 9 comments

Comments

@dharapvj
Copy link

@dharapvj dharapvj commented Jul 26, 2016

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
Copy link
Member

@mattjohnsonpint mattjohnsonpint commented Jul 27, 2016

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
Copy link
Member

@mattjohnsonpint mattjohnsonpint commented Jul 27, 2016

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
Copy link

@manojdcoder manojdcoder commented Feb 27, 2017

@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
Copy link
Member

@maggiepint maggiepint commented Feb 28, 2017

@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
Copy link

@LayZeeDK LayZeeDK commented Mar 16, 2021

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
Copy link

@gunnarSensus gunnarSensus commented Mar 16, 2021

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
Copy link

@LayZeeDK LayZeeDK commented Mar 16, 2021

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

@gunnarSensus
Copy link

@gunnarSensus gunnarSensus commented Mar 16, 2021

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
Copy link

@arstropica arstropica commented Mar 16, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants