-
Notifications
You must be signed in to change notification settings - Fork 838
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
Comments
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. 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. |
This is valid. You can review the entry from the tzdb for Europe/Dublin. You can also read about it on Wikipedia. |
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 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. |
I think this is due to limitations from
|
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. |
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. |
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. |
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. |
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. |
that fixes an issue with some LMT entries as well, see moment/moment-timezone#308
that fixes an issue with some LMT entries as well, see moment/moment-timezone#308 (cherrypicked from js-joda-timezone 60ebaf6)
Reposting from moment/moment#3001
When converting a specific datetime value to GMT or UTC the output is a bit confusing:
or this
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?
The text was updated successfully, but these errors were encountered: