DST rules not used in runtime

[zgmnkv]

Hi guys,

What I understand from the documentation - is that you don't use rules from IANA tzdata for daylight saving time transitions in runtime, but you copy transition for each year instead.
So, for example, instead of something like

zone Europe/London from 1996 uses GMT/BST 
and switches to summer time in the last sunday of march 
and back in the last sunday of october

You have

"Europe/London|GMT BST BDST|0 -10 -20|0101010101010101010101010101010101010101010101010121212121210101210101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010|-2axa0 Rc0 1fA0 14M0 1fc0 1g00 1co0 1dc0 1co0 1oo0 1400 1dc0 19A0 1io0 1io0 WM0 1o00 14o0 1o00 17c0 1io0 17c0 1fA0 1a00 1lc0 17c0 1io0 17c0 1fA0 1a00 1io0 17c0 1io0 17c0 1fA0 1cM0 1io0 17c0 1fA0 1a00 1io0 17c0 1io0 17c0 1fA0 1a00 1io0 1qM0 Dc0 2Rz0 Dc0 1zc0 Oo0 1zc0 Rc0 1wo0 17c0 1iM0 FA0 xB0 1fA0 1a00 14o0 bb0 LA0 xB0 Rc0 1wo0 11A0 1o00 17c0 1fA0 1a00 1fA0 1cM0 1fA0 1a00 17c0 1fA0 1a00 1io0 17c0 1lc0 17c0 1fA0 1a00 1io0 17c0 1io0 17c0 1fA0 1a00 1a00 1qM0 WM0 1qM0 11A0 1o00 WM0 1qM0 WM0 1qM0 WM0 1qM0 WM0 1tA0 IM0 90o0 U00 1tA0 U00 1tA0 U00 1tA0 U00 1tA0 WM0 1qM0 WM0 1qM0 WM0 1tA0 U00 1tA0 U00 1tA0 11z0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1o00 14o0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00 11A0 1qM0 WM0 1qM0 WM0 1qM0 WM0 1qM0 11A0 1o00 11A0 1o00",

I see some big disadvantages of this approach:

1. Timezone data becomes large when you copy transitions for each year, even if it's packed.
2. Timezone data can't be used without updates, we have to manually generate new transitions for future years, and data becomes bigger and bigger with each future year that we want to support.

If I understand correctly, you have code that parses IANA rules and generates timezone data in your format, and generally speaking we can adapt it to use rules in runtime.

So, my questions are:
Is this a deliberate approach or is it just an easy solution for now?
Do you have plans to support data with rules?

[timrwood]

The original implementation did use the rules and zones from the IANA tzdata. We switched away from it due to poor performance, maintainability, and memory leaks.

You can see the rationale for the change in #82.

[zgmnkv]

Ok, I see the problem.
I really like this project, and I appreciate all the team for it.
But this particular decision is not very nice in my opinion.
What if I want to operate with years like 3000, 10000? For example if I develop a game that takes place in the future.
A lot of operating systems, languages, libraries uses IANA tzdata with rules without problems, memory leaks, etc. Of course, implementing this to work fast, efficiently, without memory leaks - is not an easy task.
I'm talking not only about common web sites, but about javascript in general, because I don't know any other usable time zone support library for js.
Maybe this decision works good with some common web sites, maybe with most web sites, but as a general solution for timezones in js it doesn't work.

[zgmnkv]

I believe that all problems with performance, maintainability, memory leaks are resolvable with support for rules in runtime.

[timrwood]

Do you have a specific use case for using rules, or is it just for the theoretical savings?

Assuming that the timezone rules will be the same for the next 1000 to 8000 years is overly optimistic. There have already been 8 updates to the IANA tzdb this year, so it's highly unlikely the data will be the same for so long. If you are making a game that takes place in the future, write a plot point saying daylight saving time was abolished and save the headaches. :)

[zgmnkv]

Ok, example with game is not really good)
Actually I faced this issue when I wanted to make a chart that displays DST changes for some cities during the time. I expected that I can take a time zone, take a moment and get DST offset in minutes for this moment, I mean not depending on whether DST is applied to particular moment, just get theoretical DST offset value.
But it seems that it's impossible to ditinguish DST switch from timezone switch. Also it's impossible to check if DST is applied to current moment. Or am I mistaken?
By the way, till which year switches are generated now? I mean "all" years link on the site.

[timrwood]

The data is calculated from 1900 to 2038 for the moment-timezone-all-years.js build.

You can check if a moment is in DST using moment#isDST.

You can check the amount of time offset from UTC with moment#zone.

[zgmnkv]

I have looked at moment#isDST function...

        isDST : function () {
            return (this.utcOffset() > this.clone().month(0).utcOffset() ||
                this.utcOffset() > this.clone().month(5).utcOffset());
        },

What if it's not a DST switch, but a historical offset switch for the timezone?