$ ls -l /etc/localtime lrwxrwxrwx 1 root root 33 Apr 22 00:19 /etc/localtime -> /usr/share/zoneinfo/Pacific/Auckland
The SuperUser can use tzselect(8) to change these settings. Make sure it is set correctly! If you have it set to UTC your system time will not reflect your localtime. ntpdate(8) will set the system clock correctly, but the hardware clock will get confused. You can compare these by looking at the output of date(1) and hwclock(8).
On RedHat systems, /etc/sysconfig/clock defines the UTC variable as either UTC=true if the hardware clock is in UTC, or UTC=false if it is in local time.
Having the hardware clock set to UTC is A Good Idea, because it avoids the need to adjust the clock forward or backward an hour when daylight saving goes on or off. There is no standard, reliable way of recognizing whether the hardware clock has been set for daylight saving or not; hence it is possible, particularly if your machine boots more than one OperatingSystem and you switch between them at the wrong time, for the adjustment to be done twice, or not at all. However, you might be forced to have your hardware clock set to local time in order to maintain compatibility with another OperatingSystem that fiddles with your hardware clock for daylight saving.
The internal representation of UTC time that all Unix systems use is often known as the Unix timestamp. This value is defined as the number of seconds since 00:00.00 01-01-1970. This value is always stored in UTC and when displayed is adjusted via your time zone to display your local time.
Try one of the following:
date +%s perl -e 'print time() . "\n"'
Try one of the following:
date --date="1970-01-01 <unix timestamp> secs UTC" perl -e 'print localtime( <unix timestamp> ) . "\n"' perl -e 'print gmtime( <unix timestamp> ) . "\n"' # for UTC /usr/lib/news/bin/convdate -c <unix timestamp>
/usr/lib/news/bin/convdate -n <date string>
date --date="<date> <time> UTC" +%s
Or use the mktime(3) function available in various programming languages.
<?php $ts = mktime(11, 49, 00, 10, 17, 2004); echo strftime("%Y-%m-%d %H:%M:%S %Z<br>", $ts); putenv("TZ=UTC"); echo strftime("%Y-%m-%d %H:%M:%S %Z<br>", $ts); ?>
If you run this script you'll get output like this (depending on the TimeZone of your server)
2004-10-17 11:49:00 NZDT 2004-10-16 22:49:00 UTC
Here the value of TZ is a filename path; if it doesn' begin with a /, then it is interpreted relative to the /usr/share/zoneinfo directory (on most Linux distros). Multiple files in this directory with the same contents give different ways of specifying the same time zone; thus NZ is a synonym for Pacific/Auckland.
Excerpt from comp.risks 22.94:
Motorola reports that several GPS receivers in its Oncore line will misdisplay the date on 28 Nov 2003 at midnight UTC. For a one-second window the receivers will mistakenly report the date as 29 Nov instead of 28 Nov.
Here's why. Every couple of years or so for the past three decades, the International Earth Rotation Service has announced a leap-second because the Earth is rotating slightly more slowly than an 86400-second day would suggest. But since 1 Jan 1999, we've had an unusually long dry spell without any leap seconds. The GPS week number in the UTC correction parameter is 8 bits long, which allows for 256 weeks of unambiguous time calculation. Until now this parameter has never rolled over, but because of the dry spell 28 Nov will be exactly 256 weeks after the most recent leap second, and the rollover will contribute to the bug. http://www.motorola.com/ies/GPS/docs_pdf/notification_oncore.pdf
$ cal 1752
$ zdump -v Europe/London | grep 194[0-9]