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

LMT entries missing for some time zones #308

Closed
ThePasko opened this issue Mar 7, 2016 · 10 comments
Closed

LMT entries missing for some time zones #308

ThePasko opened this issue Mar 7, 2016 · 10 comments
Labels

Comments

@ThePasko
Copy link

ThePasko commented Mar 7, 2016

Reposting from moment/moment#3001

When converting a specific datetime value to GMT or UTC the output is a bit confusing:

moment.tz("1751-01-01T00:00:00", "Europe/Dublin").clone().tz("Europe/London").format("YYYY-MM-DDTHH:mm:ss.SSSS") -> "1751-01-01T00:25:21.0000"

or this

moment.tz("1751-01-01T00:00:00", "Europe/Dublin").clone().utc().format("YYYY-MM-DDTHH:mm:ss.SSSS") -> "1751-01-01T00:25:21.0000"

The first thing I learned here is that the 25min added is actually not a bug :)
But what about the extra 21 seconds added in both cases?? Is that a bug?

@maggiepint
Copy link
Member

My notes from the issue in the moment repo:

It appears that the Europe/Dublin timezone did indeed have a -00:25:21 offset from August 2nd 1880 to October 1st 1916.
Search for Europe/Dublin in the following file:
ftp://ftp.iana.org/tz/data/europe

I realize that your time range predates this. I think there may be something going on with how far back the IANA data goes in Moment-timezone.

@mattjohnsonpint
Copy link
Contributor

This is valid. You can review the entry from the tzdb for Europe/Dublin.

You can also read about it on Wikipedia.

@mattjohnsonpint
Copy link
Contributor

Actually, I'm going to re-open this, but only because it appears that we are somehow not importing the LMT value. The DMT value should only be in effect from 1880 to 1916. For the 1751 date provided, it should be using the LMT value of -0:25:00.

Though do keep in mind that really anything before 1970 is suspicious. The TZDB doesn't guarantee historical accuracy. It does the best it can from sources reported, but human beings really didn't keep time all that accurately in the 18th century.

@mattjohnsonpint
Copy link
Contributor

You can see the Europe/Dublin entry in moment-timezone here.

At first, I thought we were skipping LMT for all time zones, but I see many of them that have it, and many that do not. @timrwood ?

@mattjohnsonpint mattjohnsonpint changed the title When converting datetime to GMT or UTC result gets 21seconds added LMT entries missing for some time zones Mar 8, 2016
@timrwood
Copy link
Member

I think this is due to limitations from zdump, which we use to generate data files.

zdump only outputs data between 1901-12-13 and 2038-01-19, which is the range of a 32 bit signed unix timestamp in seconds.

UTC  Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:45:52 1901 UTC isdst=0
UTC  Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:45:52 1901 UTC isdst=0
UTC  Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 UTC isdst=0
UTC  Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 UTC isdst=0

@mattjohnsonpint
Copy link
Contributor

Hmmm.. Doing some research and I can't find that as a stated limitation. A few mentions related to 32-bit vs 64-bit.. Are we using 32 bit?

Also - how would you feel about replacing zdump with something more platform neutral? We could likely swap it out for pytz (python). Then it would build on Linux, Mac and Windows, and we'd have better control over the source data. (Currently you can't build moment-timezone on Windows)

Alternatively, we could look at writing our own tzdata parser in JavaScript.

@timrwood
Copy link
Member

The source for zic.c and zdump.c are both available, and we could easily download them as part of the download task.

I would much prefer to compile those as part of the build process than introduce another language dependency.

@mattjohnsonpint
Copy link
Contributor

Unfortunately, that wouldn't work. We can't count on a C compiler being available, and tzcode (including zic and zdump) doesn't build on standard Windows due to environment issues, regardless of compiler choice.

There were some recent changes posted to tzcode that are supposed to let it compile under MinGW, but I haven't tried it yet. Even then, MinGW is a very large overhead. I don't think the typical JS developer would go for that.

@mattjohnsonpint
Copy link
Contributor

FYI - I just spent the last couple of hours trying to get zic and zdump to build on mingw with no luck. I've tried cygwin, msys, and win-builds, to no avail. I'll see if I can get help from the tz list, but I still think we should be considering either a python or pure javascript solution.

@mattjohnsonpint
Copy link
Contributor

I finally have been able to make this work, getting zic and zdump to work on windows, as well as fixing various errors with Linux output of zic and zdump as well.

I'm not including zic.exe or zdump.exe in our builds, but instructions for building are in the tz list archives here.

Various grunt tasks needed updating to support this. These are in release 0.5.22, along with the repaired LMT entries.

pithu added a commit to js-joda/js-joda-timezone that referenced this issue Feb 20, 2019
that fixes an issue with some LMT entries as well,
see moment/moment-timezone#308
phueper pushed a commit to phueper/js-joda that referenced this issue Feb 24, 2019
that fixes an issue with some LMT entries as well,
see moment/moment-timezone#308

(cherrypicked from js-joda-timezone 60ebaf6)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants