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 · 4 comments

Comments

@dharapvj
Copy link

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.

@mj1856

This comment has been minimized.

Copy link
Member

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.

@mj1856 mj1856 added the enhancement label Jul 27, 2016
@mj1856

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.