On 2009-03-31_07:58:03, Alex Samad wrote: > On Mon, Mar 30, 2009 at 02:50:55PM -0600, Paul E Condon wrote: > > On 2009-03-29_11:15:15, Ron Johnson wrote: > > > On 2009-03-29 10:49, Paul E Condon wrote: > > >> On 2009-03-29_22:29:41, Strong and Humble wrote: > > >>> Good day. > > [snip] > > > > If you only have Linux on your computer, then it's clock is most likely > > > UTC. > > > > On a Linux computer, the internal clock is almost certainly *NOT* UTC, > > rather it is "seconds since Unix Epoch", often shortened to "seconds > > beg to differ, I believe the time is kept relative to UTC and the > recording method is unix time
In Linux hosts, the time that is used is a reading of the software clock on the "host", i.e. the computer. Most people choose to keep this clock set to agree with an NTP server. But the clock in the compute is Unix time, with errors associated with constantly resetting it via NTP, not UTC. Appropriate format settings in date, translate it so that it looks like UTC, but the traceablity to UTC, is ... not so good. Good enough for most computer network work, but not really up to snuff by other standards. It is 'virtually the same', or 'the same for all practical purposes', or some other phrase that indicates that you are skipping over details. My point was that the clock is a local, rather low tech piece of hardware that had been set to agree with UTC at some time in the fairly recent past, as opposed to "it's clock is most likely UTC". UTC is based on TAI, but with leap seconds. TAI has its own Epoch back in the late '50s or early '60s. It is always represented with this fact suppressed by adding into the seconds count, an offset that is based on the conventional calculation of seconds since the birth of Christ in the Gregorian calendar. > > > since Epoch", or just "Unix time". All the stuff about displaying year, > > month, day, AM/PM, and other human cultural things is done in software > > that reads the Unix clock and translates the reading into one of many > > different forms with which humans are more comfortable. > > > > The issue, for me, has been which of these human forms is displayed on > > my computer, and how do I control that choice. I think it would be > > crazy to switch to a different clock internally in the computer. It is > > seconds since Epoch, and always will be, so long as Linux/Unix/POSIX > > exists, IMHO. > > > > UTC is available as a translation. You can get it, if you want, by > > selecting "Etc:UTC" in dpkg-reconfigure tzdata. > > I believe all this does is change the default system time zone try this > > date ; TZ=UTC date > Tue Mar 31 07:57:14 EST 2009 > Mon Mar 30 20:57:14 UTC 2009 > > date is sensitive to the TZ variable > Look at one of my earlier posts. This fact is handled rather nicely in tzdata. I think you will not find any mistakes in the handling of the tranlation of the reading from the Unix clock into any time-zone format. > I am in Oz You probably have more day-to-day hassles about the International Date Line than I do here in Colorado. To me, it is largely a theoretical issue. Although I did get some feel for the confusion when my daughter lived for a while in NZ ;-) -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
