Replies: 2 comments 14 replies
-
It will be accurate to whatever version of tzdb it has, whether that is the system's or one statically included. This will be no different than any change to time zones.
As has been stated before, no (at least without an explicit opt-in). The end goal of the time crate is to reflect reality. There shouldn't be any issues parsing leap smear, as they pretend there's still 10⁹ nanoseconds in a second (despite it being slightly more). Formatting, on the other hand, could result in a value that is invalid. My initial thought on supporting this would rely on a marker trait that serializers could implement (nb: the time crate would not do so) indicating that leap seconds should be formatted a different way (how doesn't much matter at this point). |
Beta Was this translation helpful? Give feedback.
-
Fixed that. With the broken Unix behaviour on leap second timestamps, there is no unambiguous way to refer to a leap second time with them. |
Beta Was this translation helpful? Give feedback.
-
Once on startup and once every six months should suffice, given that leap seconds are currently only inserted at the end of June and December. The only thing that actually has to be synched in this specific case is the list of leap seconds. I don't think that's too much to ask.
It is not possible to simultaneously comply with RFC3339 and reject leap seconds unconditionally. Someone refusing to handle a situation that is required to be handled is not my issue, it's theirs as they're not spec compliant.
Who is requiring an unambiguous mapping of unix timestamps? I've declared no intention to do so at the least. Even leap smear doesn't do that, as some values are skipped (just nanosecond values instead of second values). It's not a bug — it's something that is universally accepted as correct. This isn't the correct place to be taking up issues with "the computing world"; I don't control what's universally accepted.
Protobuf, per what you've said, never contains a second of 60 and thus never needs to parse a leap second. I'm asking for a situation where a second value of 60 may be present (and is truly a leap second) but should be rejected. |
Beta Was this translation helpful? Give feedback.
-
That's too much to ask from any protocol that needs to communicate time information. Especially protocols that have been designed not to need this nonsense. As far as I'm aware, there are no scheduled times at which the IERS bulletins come into effect for time computations. This means that when an update is published, it must be either atomically applied across the world, or communicated with every message referring to a future moment in time in or after the upcoming leap second, for the participants to keep being in sync.
Basic sanity of software engineering? 🤷
Any value that is produced by smeared clocks can be unambiguously mapped to an UTC date-time. Traditional backward-leaping Unix clocks do not provide this property. Bug fixed. Now Unix timestamp values can be passed across the net, and everybody can be in agreement over what these values mean. A problem solved by the specification on protobuf well-known types.
Even a brief reading of the links in the original message would reveal that's no longer the case. Huge companies whose services are used by billions of people have fixed their clocks and are offering NTP time servers to others who wish to do so.
This situation arises when RFC 3339 or, in fact, any human-time serialization format is used for representing times exchanged over protobuf. You can claim all you want that this is not The Proper Way, reality, etc. and all software engineers out there should instead use intricate time-dependent conversions involving tzdb to get their international standard-compliant time representations, but this is, I'm afraid, not how most software engineers approach problems. As evidenced by the Go implementation, which happens to be the most widely used one for protobuf implementations. If time-rs does not provide equivalent functionality, people will just go elsewhere. |
Beta Was this translation helpful? Give feedback.
-
I am suggesting it as a possibility for if both sides of the communication absolutely must be up to date. If that's not the case, there's no harm in using an out-of-date version. The simpler solution, as you're aware, is to perform regular system updates. This is recommended regardless of the decision made here.
Announcements are made five to six months ahead of time. For example, that there will not be a leap second at the end of 2021 was announced in July. As such even syncing every March and September, for example, would be sufficient. As I said above, updates should be made on a regular basis regardless for security purposes. There are non-network ways of receiving leap second notifications, but those are presumably in limited use.
When you stretch 86,400 seconds into 86,401, you are losing information, in this case on the order of 11µs/s. That means there are ~11,000 values per second that can not be mapped at all. That is what I was saying in my previous comment. With regard to it being a bug, the definition of Unix/POSIX time requires leap seconds be ignored:
Additionally, NTP best practices recommends against leap smear in most cases:
At this point is should be clear that what Google et al. are doing is contrary to established standards and best practices. The size of the companies is wholly irrelevant. They have not "fixed" their clocks; they are not following the standards and best practices that I have linked.
I looked into protobuf a bit, as I've never directly used it. As it turns out there is no specification of what format a time takes. The Go language may expect a certain format, but that doesn't mean that protobuf requires it. I am implementing the RFC3339 specification to a tee. Go not doing so is not my concern. If they're claiming to follow RFC3339, they are objectively wrong due to not handling leap seconds. Setting that aside, I had dismissed your claim of protobuf previously due to the fact your claim that it doesn't support leap seconds. If this were the case, then no formatted value would ever contain 60 as the seconds value, and thus the time crate's handling of such a value should be irrelevant as it will never be encountered in that circumstance. That is why I am, yet again, requesting an example of a situation where a formatted value has 60 as the seconds value and the parser should reject it. There are multiple instances of inflammatory language in your most recent comment. Please remember that there is a code of conduct that must be followed at all times. Please refrain from additional uses of such language. |
Beta Was this translation helpful? Give feedback.
-
How would the (possibly indirect) users of the crate who do need consistency at all times be taught about this? Since it will work almost all the time without synchronization, there is no way to become aware of the need to keep tzdb in sync or communicate updates in band. Until a once-in-a-decade bug hits.
An even simpler solution is to use a time reference scheme that does not rely on an external, dynamically updated data source, and allows stable time computations into the future.
At what precise moment must Alice and Bob from my examples apply the newly announced leap second update?
It's questionable whether those exact nanosecond values are precious. Time is a physical quantity; when you are using a fixed precision representation of it, you have to use some approximation of a real time moment. Furthermore, the precision of determining time on a computer is subject to clock precision, clock drift, system call and network latencies etc. I'm not aware of any standard requirements on specific precision for time implementations. When you are parsing an RFC 3339 string that has more than 9 digits in the subsecond part and your representation can only be precise up to nanoseconds, you are losing some information too. The only issue where this lossiness matters is when you need to convert between smeared and non-smeared time. But that's another reason to avoid such conversions for the users who are only required to use one of these time reference schemes.
And then what Unix clock implementations do? They set their clocks back and produce timestamps as if they referred to the previous second again. Something they take pains not to do at any other times, to the point of deliberately skewing their clocks in locally applied mini-smears. It would be better if system calls to get real time clock blocked until the leap second has passed, but this is not what the implementers chose to do (I guess some OSes just update an in-memory location or a hardware register that can be read by every process so the clock is non-blocking). Regarding strict POSIX compliance, it would be better if this failed in some way rather than producing a bogus value: OffsetDateTime::parse("2016-12-31T23:59:60.999999999Z", &Rfc3339).unwrap().unix_timestamp()
There is difference between NTP and what the system clock provides. NTP is sufficiently equipped to inform the clients about leap seconds, but Unix (and other OSes') clock APIs aren't. Hence the need for leap smear – the smeared time needs to be synchronized across networks, too.
I thought I might be in the wrong about what Go libraries really do, so I did some research. As it turns out, my use case can be widened to interoperability with any applications using Golang's Yes, these implementations are not in compliance with the letter of the specification. But the demand for at least optional interop with them is bound to be huge. Specifically, as a developer of tendermint-rs, I'm interested in our implementation being in agreement with its Go counterpart over the distributed ledger protocol, and if time-rs unconditionally enables silent conversions from leap second times to Unix timestamps, or time arithmetics that account for leap seconds, we'd have to turn elsewhere for our time domain representation needs.
Noted. It would be nice to also apply the same guidelines to e.g. #406 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
A good blog post from engineers at Meta. |
Beta Was this translation helpful? Give feedback.
-
|
Already read it! Personally I'm in favor of getting rid of them completely. Even with the recent announcement (not mentioned in that post) that there will not be a leap second at the end of 2022. |
Beta Was this translation helpful? Give feedback.
-
Proper handling of UTC leap seconds is a complex matter, which makes it a rich breeding ground for bugs and poorly conforming implementaitons. Furthermore, it makes calendar time computations themselves dependent on context data that changes in time.
At this point,
timedoes not support leap seconds internally. The only concession is made in the RFC 3339 parser, where inputs with a second number 60 are allowed with the proviso of the referred moment being in a valid leap second (before #412 or a similar change is in, there are in fact no checks whatsoever, but this should be fixed). The parser approximates that to the last nanosecond of the preceding second 59 and calls it a success.Now, the discussion in #406 has made me wonder about future direction of this library. As it is planned to implement support for tzdb which is supposed to also provide leap second data, will time-rs be suitable for:
Beta Was this translation helpful? Give feedback.
All reactions