On Wed, Apr 1, 2015 at 3:03 PM, Anselm Lingnau <[email protected]> wrote: > Yes, but the epoch (1 Jan 1970 0:00 UTC) *is* a specific point in time, > a “here and now” if you will,
Understand by "here and now" ... I mean the system was actually _active_ when the _actual_ time in the world really was 1 Jan 1970 00:00:00 UTC and it recorded those events. it's important one doesn't interpret that phrase any other way. ;) > and the Linux kernel clock counts seconds > in sequence starting at that point in time. Er, I don't think you mean "count," but "offset." To flip back to my point "here and now," there is a difference between the kernel "counting trough" the actual date, and having an "offset" from that date. I think my prior statement confused you and set you down the wrong path. > Programs that want to display the current date and time to users in > “civic” terms obtain the second count from the Linux kernel (a number > going on 1.5 billion, these days) and format that according to the rules > for the current time zone. The same applies to programs that want to > display things like file system time stamps. Remember that Zoneinfo != 32-bit time_t. ;) But Zoneinfo really doesn't go beyond the early Almanacs, largely 18th century, although some go to the Gregorian of the 16th (IIRC). > It is just as well to remember that the Linux kernel clock (and > associated data type, time_t) is only good for obtaining the current > time (in seconds from the epoch, as described) and dealing with OS-level > time stamps. You're mixing concepts at this point. Zoneinfo, namely the Olson DB, is not related to time_t. How the system "ticks" is not of its concern. The offset is what matters, when UTC is set. Again, UTC is best for recording an event "here and now," when it actually happens. Recording past events post-event, and scheduling future dates, are not ideal to do in UTC. Again, there are entire whitepapers written on this. ;) > It is not particularly useful for general calendrical > calculations because of its limited range – in theory, from the epoch¹ > to whenever the counter rolls over, which for a 32-bit time_t will occur > in 2038² –, so if you're dealing with things like life insurance you'll > run into problems if you plan to do it based on time_t. Again, Zoneinfo and Olson DB != to time_t. Put time_t aside for this discussion. ;) Unless I"m failing to understand how it's relevant, of course. > Hence, reasonable programming languages include support for dates and times > that is not tied to the Linux kernel's notion of time. Like the ones that also use Zoneinfo, because Olson DB is _not_ related to time_t. ;) Even Windows and core libraries/subsystems these days. ;) > Such support is unlikely to use the GNU libc's API due to its limits, Again, don't confuse GNU LibC support for time_t and Zoneinfo. Case in point ... > but is virtually certain to use the Zoneinfo database (at least if the > developers of that support have done their homework), and that's > presumably where Bryan's idea of taking the time zone name from > somewhere application-specific comes in, since the applications in > question may or may not look at TZ > (I think they should, but that's just me). Zoneinfo is just the offset from whatever the RTC is at, currently. Ideally this should always be UTC. And when the actual, real tick happens at a time in UTC, an event can be safely recorded. Any past dates that are post-event recorded, should be localtime. Same with any future scheduling. > Anselm > ¹ It turns out that GNU libc does mostly the right thing with negative > time_t values, but that only lets you go back to 1901 with a 32-bit > time_t. The oldest living person in the world was born in 1898 (that > we can verify, anyway), so there's another problem right there. > ² One strategy for getting rid of the 2038 limit is trying to make > time_t a 64-bit value, and how to accomplish this without breaking too > much existing code in the process is one of the ongoing challenges in > Linux kernel development. We have 23 years to sort this out for good. All this doesn't matter for Zoneinfo and the Olson DB format. -- bjs _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
