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

Disambiguation behaviour when converting DateTime skipped by DST transition #317

Closed
ptomato opened this issue Jan 20, 2020 · 4 comments
Closed

Comments

@ptomato
Copy link
Collaborator

ptomato commented Jan 20, 2020

Follow up from #316.

Currently in the polyfill, disambiguating a wall-clock time that is skipped when setting the clock an hour forward for DST will give a time that's either 1 hour earlier or 1 hour later.

@gibson042 >

This seems wrong to me... it means that tz.getAbsoluteFor(skipped_02_45.minus("PT50M"), "earlier") is later than tz.getAbsoluteFor(skipped_02_45, "earlier")! Shouldn't the "two possible absolute times" for a time of day skipped by a positive transition be "immediately before the transition" vs. "the matching time in the pre-transition offset" (e.g., converting a skipped 02:45 to 01:59:59.999999999 vs. 03:45)?

@ptomato
Copy link
Collaborator Author

ptomato commented Jan 20, 2020

I don't have a strong opinion one way or the other, but I can think of the following reasons that mildly support keeping it the way it is:

  • The current behaviour is how moment-timezone does it.
  • The other DST transition (setting the clock back) gives you two possible times that are an hour apart, so there's a sort-of symmetry argument to be made here.

@gibson042
Copy link
Collaborator

The current behaviour is how moment-timezone does it.

Can you demonstrate what you mean? I don't see any way to get anything other than a post-transition value for skipped times of day.

> moment("2020-03-08T02:45").tz("America/New_York").format()
'2020-03-08T03:45:00-04:00'

@ptomato
Copy link
Collaborator Author

ptomato commented Jan 20, 2020

Oh, you're right, actually; scratch that reason.

@gilmoreorless
Copy link
Contributor

e.g., converting a skipped 02:45 to 01:59:59.999999999

That's not a great approach to take. It would be inconsistent with other languages/libraries that handle disambiguation, and would be a very unintuitive result.

Imagine a task scheduled hourly in America/New_York with the equivalent UTC timestamps listed, using that process above:

America/New_York => UTC
2020-03-08T00:45 => 2020-03-08T05:45
2020-03-08T01:45 => 2020-03-08T06:45
2020-03-08T02:45 => 2020-03-08T06:59:59.999999999  <--- Unexpected
2020-03-08T03:45 => 2020-03-08T07:45

If I saw that result in my application, I'd assume there was a bug somewhere.

@ryzokuken ryzokuken added this to To do in Finalize polyfill via automation May 20, 2020
@ryzokuken ryzokuken added this to To do in Finalize documentation via automation May 20, 2020
@ryzokuken ryzokuken moved this from To do to In progress in Finalize polyfill May 20, 2020
ptomato added a commit that referenced this issue May 20, 2020
This was requested in the original cookbook issue and is now possible
using TimeZone.getPossibleAbsolutesFor().

Closes: #317
Closes: #318
ptomato added a commit that referenced this issue May 21, 2020
This was requested in the original cookbook issue and is now possible
using TimeZone.getPossibleAbsolutesFor().

Closes: #317
Closes: #318
ptomato added a commit that referenced this issue May 21, 2020
This was requested in the original cookbook issue and is now possible
using TimeZone.getPossibleAbsolutesFor().

Closes: #317
Closes: #318
ptomato added a commit that referenced this issue May 21, 2020
This was requested in the original cookbook issue and is now possible
using TimeZone.getPossibleAbsolutesFor().

Closes: #317
Closes: #318
ptomato added a commit that referenced this issue May 22, 2020
This was requested in the original cookbook issue and is now possible
using TimeZone.getPossibleAbsolutesFor().

Closes: #317
Closes: #318
Finalize polyfill automation moved this from In progress to Done May 25, 2020
Finalize documentation automation moved this from To do to Done May 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants