Bryan J Smith wrote: >> On Linux, determining the actual (civic) time is just a >> matter of formatting the second count from 1 Jan 1970 0:00 UTC into >> something that is appropriate for that particular user, and this makes >> things like the remote-login case straightforward to handle for >> individual users; the operating system kernel's job is just counting the >> seconds accurately. > > Just remember ... UTC only works for "here and now."
Yes, but the epoch (1 Jan 1970 0:00 UTC) *is* a specific point in time, a “here and now” if you will, and the Linux kernel clock counts seconds in sequence starting at that point in time. (This is disregarding leap seconds, which the Linux time subsystem ignores in any case.) 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. 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. 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. Hence, reasonable programming languages include support for dates and times that is not tied to the Linux kernel's notion of time. Such support is unlikely to use the GNU libc's API due to its limits, 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). 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. -- Anselm Lingnau ... Linup Front GmbH ... Linux-, Open-Source- & Netz-Schulungen [email protected], +49(0)6151-9067-103, Fax -299, www.linupfront.de Linup Front GmbH, Postfach 100121, 64201 Darmstadt, Germany Sitz: Weiterstadt (AG Darmstadt, HRB7705), Geschäftsführer: Oliver Michel _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
