Re: A structured format for dates?

> On Jun 16, 2022, at 15:06, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> --------
> Austin William Wright writes:
> 
>> Quick, off the top of your head: What happens to the Unix epoch when it 
>> passes through a leap-second? What about a negative leap second? [1]
> 
> As I mentioned in another email, the leap-second situation has
> gotten geophysically rather murky.
> 
> I personally think we are unlikely to ever see another leap-second.
> 
> Either they will be abolished before the next one becomes necessary
> or they will become so unmanageable, that that we either get a
> standarized smear algorithm or switch to more predictable time-scales.

While plausibly true, at the time of writing, this is not a certainty.

> 
>> I figure, if fractional seconds are important, then being able to 
>> represent a leap-second is probably of some importance.
> 
> Fractional seconds are relevant many times every single second.
> 
> Leap seconds are at most relevant every 50 million seconds, currently
> have not been so for 220 million seconds and are unlikely to be relevant
> for at least the next 100 million seconds.

I don’t believe “works 99.999998% of the time" may be good enough.

If your program crashes and won’t start back up every 50 million seconds because it doesn’t know how to handle a leap second jump, this suddenly becomes quite significant. Which has happened to me on MongoDB.

> 
> The absolutely simplest, fastest and least error-prone, both in
> development, testing and usage, is to ask the kernel for a time_t
> and render that as a decimal number.

I’m not making a serious argument for the mandatory support of leap seconds. time_t is by definition an integer without sub-second resolution, so the appearance of leap seconds isn’t terribly meaningful.

Rather, if support for fractional seconds is important for any reason at all, then it stands to reason that 1-second discrepancies might cause a few problems. We can either support leap seconds (which for our purposes is nothing more than permitting ":60"), or, take a look at why sub-second resolution would be important to begin with.

Let me propose a different argument for your case: UTC is inherently discontinuous, so if we are not going to have a way to encode these discontinuities, then applications should at least be robust against sudden system clock changes, including into the apparent past. But again, it’s not clear to me that this is a reliable way to solve the problem if certain servers are just going to crash on you.

Cheers,

Austin.

> 
> Making leap-second handling a HTTP requirement in the current
> situation would utterly stupid.
> 
> Poul-Henning
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 17 June 2022 00:21:22 UTC