Re: strftime(3) oddities with %s, %z

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> ...??  You're concerned about the interface design lasting past
>> Gregorian 34737 (or 2147485617, if you abandon <32-bit ints)?
> I am more concerned that any time_t value can be converted to a
> struct whatever, without overflowing the year field, which is not
> true now.

Fair enough.  When I moved time_t to 64-bit in the versions I use, I
ran into that.  I more or less ignored the issue, though; a few trials
with date -u -r indicate that anything converts to _something_, though
some values seem to make something somewhere in the chain hiccup (one
value results in date printing "Sun Jan  7 13:56:15 UTC 000(", for
example, on a 32-bit machine; on a 64-bit machine, it appears to
infinite-loop); I should look at that someday.  I maybe should try
converting tm_year to 64 bits as well (but see below).

> That's important, so things like fsck (even stat(1)) can print out
> what is in a time field, in a rational format, even when the inode
> has bee trampled all over by garbage - rather than either dumping
> core, or resorting to printing the time_t as an integer.  Being able
> to map time_t -> struct whatever is a necessary step for that to
> work.

Yes, but it's not necessary to map it to a _correct_ value.  For those
purposes, it would be enough to convert anything out of range to, say,
(proleptic) Gregorian year 9999, or 1000000, or some such.

I do agree it would be better if the times representible in a time_t
were a (not necessarily strict, though it's unlikely the two ranges
will ever match exactly) subset of those representible in a struct tm.

> [time_t] (integer part at least, if it were implemented as a float,
> which posix doesn't permit but I think C does, [...])

I think you're right about C, at least as of C99.  7.23.1 #3 says

       [#3] The types declared are [...];

               clock_t

       and

               time_t

       which are arithmetic types capable  of  representing  times;
       and [...]

and #4 says

       [#4] The range  and  precision  of  times  representable  in
       clock_t  and  time_t  are  implementation-defined.  [...]

However, it also defines tm_year as int.

I also note that difftime, which computes the difference between two
time_ts, is defined to return double.  And the definition of time,
which "determines the current calendar time", says that "[t]he encoding
of the value is unspecified".

I don't see any good way to reconcile these.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B