I haven't done the calcs to confirm my impression of what these numbers
might mean, but it seems to me that the expression given calculates
a number of seconds by taking the current (tm_ ...) time in years,
days, hours, minutes, seconds, and counting the seconds as 1, the
minutes as 60s, the hours as 60mins (3600s), the days as 24hrs
(86400s), and the years as 365days (31536000s - no I haven't checked).
Then they add an extra day (86400s) per normal (|4) leap year.
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.
Are they trying to tell us that this number should be the number of
real live (UTC) seconds since the epoch?
If so, then that implies that we can't be doing RTC adjustments of
tm_sec every year by a leap second. Because if we do, at 1s before
midhnight this calculation will be right (right number of elapsed seconds
given), and at 1s after midnight on a leap second year the calculation
will be wrong.
What this number will give us, if we change RTC to match UTC, is the
number of "fake" seconds since the epoch. And it will have to change
non-monotonically to be right all the time (are seconds taken away
sometimes? I think so).
> The questionable decision at least in my mind is the translation between
> "seconds since the Epoch" and struct tm. The POSIX definition ignores
yes
> I agree that this wasn't their finest hour, but there really isn't a
> good solution to this problem. Their solution is self-consistent and
> well defined, IMO. To quote their rationale, "it is important that all
> conforming systems interpret "536 457 599 seconds since the Epoch" as 59
> seconds, 59 minutes, 23 hours 31 December 1986". If this is the goal
> (and there are valid reasons for that goal --- take for example network
> protocols that send times around as "19861231235959Z") then their
> solution is the only valid one, given that when leap seconds occur is
> not predictable more than a few months in advance.
Clearly we should only use local clocks.
Peter - oh god, this is going to go on and on ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu