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

Leap seconds #4

Open
mlms13 opened this issue Aug 11, 2019 · 0 comments
Open

Leap seconds #4

mlms13 opened this issue Aug 11, 2019 · 0 comments

Comments

@mlms13
Copy link
Member

mlms13 commented Aug 11, 2019

I don't have the need or motivation to implement this at the moment, but here is maybe a strategy:

  • add a lookup table of days with known leap seconds ((Year, Month) might be enough information because leap seconds always happen on the last second of the last day of the month in which they occur)
  • LocalTime can still assume 86,400 seconds per day, and can clamp and wrap accordingly
  • ...but!! in the context of a date (e.g. LocalDateTime, Instant), the last second of the day can instead be clamped to 60 on specific days, similar to how we clamp dayOfMonth differently in different year/month combinations
  • addSeconds and addMilliseconds will need to be adjusted to see if they cross a leap-second boundary, when adding to a datetime
  • formatters should write 23:59:60.xxxx when applicable

It's debatable whether this is worth it. The lookup table will need to be updated each time a leap second is added, which doesn't happen on predictable intervals, and often doesn't happen with much advance notice. JS dates don't know or care about leap seconds, which makes the interop story a bit unclear.

What's more, most people don't care about to-the-second accuracy with datetimes, and industries that do (e.g. astronomy, high-frequency trading) usually have their own standards for dealing with times and aren't overly concerned with UTC.

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

1 participant