If my interpretation is correct, then this expression (1) will go weird
at centuries that are not leap years, (2) doesn't sync by some number
of leap seconds every year.
Yes, but that's OK, because the 2000 *is* a leap year. (It's divisible
by 100, but years which are divisible by 400 are an exception to the
divisible by 100 rule, so while 1800 and 1900 were not leap years, 2000
is a leap year).
Are they trying to tell us that this number should be the number of
real live (UTC) seconds since the epoch?
No, what they're saying is that how you convert the number of real live
(UTC) seconds since the epoch *to* tm_year, tm_mon, etc. That means
that tm_sec will not necessarily be "correct" (it will be off by 14
seconds at the moment, compared to wall clock time that does include
leap seconds adjustments).
In other words, the number of real live seconds since the epoch is the
fixed point. time(0) is defined as returning the number of seconds
since midnight January 1, 1970 (UTC). This has a well-defined meaning
regardless of leap seconds. What POSIX in effect fudging is the
converstion between time(0) and struct tm, since they're not including
leap seconds in that conversion.
Again, I'm not defending their decision (although I understand it); as I
said earlier, there really is no good solution --- leap seconds really
do screw a lot of things up.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu