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
Creating Time with Time.utc
or Time.local
should wrap 60 seconds around if not a valid leap second
#2426
Comments
It is entirely possible we could raise this issue with |
This is the reason #2223 Is still open - specifically most specs for I've also just finished doing a bunch of research as to how this is handled in POSIX systems. Specifically, https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16 gives a bunch of information as to what can be expected from POSIX itself. e.g. Leap seconds don't "exist". This can be seen by using $ date --date='TZ="UTC" 2016-12-31T23:59:59+00:00' +%s
1483228799
$ date --date='TZ="UTC" 2017-01-01T00:00:00+00:00' +%s
1483228800 ☝️ There should be an extra second in there. Note, date throws errors when trying to create any time with 23:59:60, regardless of whether that is a valid leap second or not. The somewhat annoying part from Ruby docs, is that leap seconds is only mentioned here: https://ruby-doc.org/3.1.2/Time.html#method-c-utc with respects to "seconds is 0..=60" essentially. This leads me to thinking that we should impement this in |
I wonder if this is the sort of thing where we can use an MRI repl to generate times for all of 2015 and 2016 with 60 seconds in a time stamp, see what it spits out, and add a functional test for it. If it's a simple as always rolling over or hardcoding when the leap seconds are (there aren't that many of them), let's do that. Probably makes sense to have tests for all other leap second time stamps as well. |
Thanks for digging on this @b-n 🙇 |
Ah, you triggered a thought in me just now. The reason I started looking at POSIX time, was due to how ruby And now I just realised what is going on. $ date --date='TZ="right/UTC" 2017-01-01T00:00:00+00:00' +%s
1483228827
$ date --date='TZ="right/UTC" 2016-12-31T23:59:59+00:00' +%s
1483228825
$ date --date='TZ="right/UTC" 2016-12-31T23:59:60+00:00' +%s
1483228826 Ref: https://www.ucolick.org/~sla/leapsecs/right+gps.html which TL;DR: some design decisions in the past meant POSIX needed a new timezone to be able to support proper UTC. So, the scary part with the I haven't look at it yet, but I suspect we just have to hard code it as you say. Part of me wonders whether we can upstream it into Funnily enough, that |
Slight oof. It appears there is a Ref: https://github.com/Kijewski/tzdb/blob/v0.5.x/make-tzdb/src/main.rs#L92-L94 And specifically compare the |
@lopopolo So, I think we're a bit blocked on the idea of getting leapseconds working (for now). If we want to get leap seconds working, then we've got a couple of options:
For the interim however, it feels like we should turn off the leapseconds test. I don't know of a way to do this apart from patching over the test in |
@b-n I marked this as blocked. We can leave it open for now, but I think there's probably some other work we can take on before getting back to this. The reliance on ENV for setting timezone here isn't something I think we should feel required to tie ourselves to. |
I've been trying to clean up ruby
spec
forTime
, and this is one of the failures in this specific suite: https://github.com/artichoke/artichoke/blob/trunk/spec-runner/vendor/spec/core/time/shared/gm.rb#L59-L69TZ
and then retrieving this information from the operating system. MRI then uses a bit of this information for parsing valid leap seconds etc. Artichoke only uses the environments local timezone for getting the offset, and thus the information about leap seconds is lost/not used.artichoke/spinoso-time/src/time/tzrs/offset.rs
Lines 147 to 155 in af5fcd2
The below
MRI:
Artichoke: (after #2425 is merged)
I believe this is a result of this: https://docs.rs/tz-rs/latest/tz/struct.DateTime.html#method.find which will return the same information it is provided, even if the leapsecond isn't valid.
The text was updated successfully, but these errors were encountered: