tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?



    Date:        Thu, 13 Dec 2018 03:55:12 +0100
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <70762ce1-90e5-eb8e-acc0-6f4d9a5810de%gmx.com@localhost>

  | Storing negative times is a generic open topic so I defer myself from
  | discussing it.

It is, and I agree, it is pointless.

  | It's the current (since ever) consensus (expected by
  | software) among C systems to implement it as signed,

These days, yes, but most of that software is really broken.   time_t
(and the related timeval, timespec, bintime) is not really suitable for
storing times/dates for most purposes.    time_t (or much earlier int t[2])
was designed as a way to deliver the current time, and to mark the
current time (as in the mod time of a file, etc) - anything much more
than that and there will eventually be problems.

  | it originated probably from the time when all numbers in C were
  | signed and this remained unaltered.

Unsigned numbers existed in C long before time_t ... and
even before they were formalised, they were used in the sense that
in any 2's complement system the only difference between a signed
and unsigned number is how you choose to interpret it.   printf had
%u before C had unsigned.

It didn't remain unchanged either actually, time_t was unsigned for a
while in the BSD world.

I know, because I made that change...   It was undone not because
it was the wrong thing to do, but because there was too much software
that was badly written and couldn't cope ... in particular, (time_t)0
did not produce Dec 31 19:00:00 1969 in (what is now) 
America/New_York but something in February 2106 (or whatever)
and that was confusing...    (I had not noticed, as I was east of Greenwich
and the issue did not arise ... none of the current timezone code existed
at the time, so testing was not so easy)

That is, simple bugs (doing calcs using time_t types on data that was
not a timestamp).

If it had not been for those bugs, we might have had unsigned time_t
being much more common today, we would not have needed to switch
to 64 bits nearly so soon (by the time that was needed, simple "int"
might be 64 bits) and software that wanted to store dates/times to
represent history would have had to do it some other way, and most
likely would have had less time related bugs because of it.

kre




Home | Main Index | Thread Index | Old Index