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

Update tzdb parser #77

Closed
cquiroz opened this issue Aug 21, 2018 · 7 comments
Closed

Update tzdb parser #77

cquiroz opened this issue Aug 21, 2018 · 7 comments

Comments

@cquiroz
Copy link
Owner

cquiroz commented Aug 21, 2018

As discussed on gitter

@cquiroz I got it to work by setting dbVersion := TzdbPlugin.Version("2018c") - So it seems that the tzdb format has changed in tzdb in 2018{d,e} and your parser somehow does not understand that change.
If you manually start a travis build, I bet that the tests will fail.

Thanks @ahjohannessen for reporting this

/cc @ahjohannessen

@cquiroz
Copy link
Owner Author

cquiroz commented Oct 5, 2018

I'm trying to reproduce this but it seems I can use newer tzdb versions just fine

@cquiroz
Copy link
Owner Author

cquiroz commented Oct 7, 2018

Actually it is a real issue in certain conditions. I'll keep searching the root source

@cquiroz
Copy link
Owner Author

cquiroz commented Oct 8, 2018

This is now fixed in sbt-tzdb. I'll make a release of scala-java-time but you don't need that to get this fixed, it would be enough to update the plugin

@ahjohannessen
Copy link

👍

@ahjohannessen
Copy link

@cquiroz Is it safe to upgrade tzdb? I noticed that you had to split tests for SJS and JVM because of negative offsets.

@cquiroz
Copy link
Owner Author

cquiroz commented Oct 10, 2018

some background:
In tzdb 2018d/e negative DST and save were added for a few european timeo zones, notably Europe/Dublin and a couple of others. Implementations should be able to parse this change but are not forced to use it.

That change broke the parser used in scala-java-time and that has been fixed and it is also in use.

The Java side is able to parse the change but it doesn't use it, hence the difference. I can't tell when the java side will be updated if ever (threeten.bp)

IMHO this is safe to upgrade, but I'm unable to test all possible cases

@ahjohannessen
Copy link

Ok, I see. Thanks for explaining this 👍

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

No branches or pull requests

2 participants