Bug interpreting times in the "overlap" period during fall DST change.

[dcosson]

In testing out js-joda and comparing it to the java version, I noticed once bug. In the "overlap" period at a daylight savings boundary (e.g. fall in the US), there are two different offset values for the same time.

In the Java implementation, it works as expected:

jshell> import java.time.ZonedDateTime

jshell> ZonedDateTime.parse("2017-11-05T01:00:00-07:00[America/Los_Angeles]").toInstant().toString()
$2 ==> "2017-11-05T08:00:00Z"

jshell> ZonedDateTime.parse("2017-11-05T01:00:00-08:00[America/Los_Angeles]").toInstant().toString()
$3 ==> "2017-11-05T09:00:00Z"

jshell> ZonedDateTime.parse("2017-11-05T02:00:00-08:00[America/Los_Angeles]").toInstant().toString()
$4 ==> "2017-11-05T10:00:00Z"

js-joda interprets "2017-11-05T01:00:00-07:00[America/Los_Angeles]" as "2017-11-05T01:00:00-08:00[America/Los_Angeles]" which is actually a different time (it should be the second 1 am, i.e. it comes just after 1:59 am)

JSJoda.ZonedDateTime.parse("2017-11-05T01:00:00-07:00[America/Los_Angeles]").toInstant().toString()
"2017-11-05T08:00:00Z"
JSJoda.ZonedDateTime.parse("2017-11-05T01:00:00-08:00[America/Los_Angeles]").toInstant().toString()
"2017-11-05T08:00:00Z"
JSJoda.ZonedDateTime.parse("2017-11-05T02:00:00-08:00[America/Los_Angeles]").toInstant().toString()
"2017-11-05T10:00:00Z"

The spring doesn't have a problem in JSJoda.

Not sure if this bug belongs in js-joda or js-joda-timezone

[pithu]

Hi,

thx for reporting,

looks like a bug in the DateTimeFormatter / ZoneId Parser in the js-joda core library.

I will have a look.

[pithu]

Hi @dcosson

I cant reproduce the issue, neither with the latest threeten backport nor the latest jdk 8 version see groovy test script. I get the same results as with js-joda (see the 2 commits above).

A look in the threeten code says that the offset is ignored if a zone id is supplied. In case of an overlap the earlier offset is used, typically corresponding to "summer". Basically its the same behavior as described here LocalDateTime.atZone

What jdk version did you use for your jshell example ?

[dcosson]

That's interesting I guess this bug (or maybe intentional behavior) goes pretty deep.

I tested it on the latest openjdk 9 version on docker hub, just because java 9 has jshell built-in. I ran it as: docker run -it openjdk:9-b170-jdk jshell

[dcosson]

The line that made me think the version I'm seeing in jdk 9 is correct was in the threeten docs

It says "In an overlap there are local date-time values with two valid offsets." which makes me think that when passing in both offset and timezone (which is otherwise redundant outside of this 1 hour a year), the intention was to respect the offset if it is one of the two valid offsets within the timezone.

[pithu]

Interesting: "jdk9 early access" behaves different then jdk8 and threeten.

So i wouldn't call it a bug, but a different interpretation of an edge case. Probably your issue should go to the jdk team. The question is, why jdk9 changes the behavior for that case

[pithu]

I forwarded the question to threeten backport project -> ThreeTen/threetenbp#73

[pithu]

Its a bug in threeten backport and jdk8 and therefore in js-joda. its fixed in jdk9. see ThreeTen/threetenbp#73

The proposal is to prioritise the offset if zone and offset is present.

We will fix it in that way!