Bryan J Smith wrote: > I think my prior statement confused you and set you down the wrong path.
I think we're really talking past each other here. > But Zoneinfo really doesn't go beyond the early Almanacs, largely 18th > century, although some go to the Gregorian of the 16th (IIRC). Not really. For Germany – “Europe/Berlin” to be exact –, for example, Zoneinfo (at least on my system) starts in 1893. Going much farther back would be difficult in any case because Germany as we know it today (more or less) didn't exist before 1871, and you would have to differentiate between the local time conventions of any of a couple of dozen independent states which made up the pre-Empire German jigsaw ;^) (This gets interesting because not only were the time zones all different – people would define their local “mean solar time” such that the sun was due south at 12 noon even in different towns within the same state, which was mostly OK until the invention of modern conveniences like the railroad and telegraph – but the Gregorian calendar reform and its omission of 12 days from the calendar was enacted at different times depending on whether the state was Catholic or Protestant.) If you go back far enough you run into issues like the one where the year doesn't change on 1 January but some other date (such as 25 March). I'm not sure, offhand, whether Zoneinfo can handle this. > You're mixing concepts at this point. Zoneinfo, namely the Olson DB, > is not related to time_t. I'm aware of that, thank you. > Unless I"m failing to understand how it's relevant, of course. I just wanted to point out the difference between the Linux kernel's notion of time (which is also mostly GNU libc's notion of time, since C doesn't really offer a lot in terms of time manipulation) and a more generally useful notion of dates and times like that supported by, e.g., the Python datetime and tz modules. The former uses Zoneinfo because it is convenient for converting kernel time stamps to civic times, and the latter uses Zoneinfo because it is the Right Thing to do. As you say, the two are largely independent, but they touch where it is possible to convert a kernel time stamp (as obtained through time(2) or stat(2)) to the other subsystem's format (such as a Python datetime object) and vice-versa. > Ideally this should always be UTC. And when the actual, real tick > happens at a time in UTC, an event can be safely recorded. The ”ticks” of the kernel clock on a Linux system have no concept of time zones in the first place because they are just a monotonous count of seconds starting from the epoch (1 Jan 1970, 0:00 UTC – the “UTC” here is part of the definition of the epoch but has nothing to do with the actual ongoing timekeeping). We pretend that the system has been counting from the epoch by initialising the count to the correct number of seconds (approximately 1.5 billion these days) when the system is booted, either by calculating backwards from the CMOS-based RTC (if there is one) or by referencing a time server (if there is one) or however. When a suitable event happens (e.g., you create or modify a file on the file system) the system just uses that number of seconds as the timestamp. This is not UTC in any way, shape, or form, but you surely know that and we're just talking past each other again ;^) If you later execute “ls -l”, it is the libc's job to format the timestamp (in seconds) such that it looks like a (local) date and time, as a convenience to you (the user). > Any past dates that are post-event recorded, should be localtime. > Same with any future scheduling. The problem comes in, for example, when you're using “cron” or “at” (to stay within the scope of LPIC-1). It is intuitive to use local time to schedule such events, but you need to pay attention because if you schedule something to happen at 2.30am every night then under the current rules for DST that particular time on the wall clock does not actually occur during one night in late March (European convention) but it occurs twice during one night in late October (European convention again). Does that mean that your cron job should be executed not at all on the March night but twice on the October night – or can we somehow finesse things such that it is just executed once a night no matter what happens to the clock on the wall? To make things even more inconvenient, the canonical cron implementation (Vixie cron) restricts itself to the system default time zone so even if you have a different time zone set using TZ, the times in your personal crontab will be interpreted according to the system default time zone set in /etc/localtime (you can set TZ in your crontab file but cron won't care although processes started by cron should). The at service, on the other hand, is perfectly happy to obey a TZ-set non-default time zone for scheduling jobs. Anselm -- 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
