Penguin
Recent Changes
Annotated edit history of TimeNotes version 25, including all changes. View license author blame.
Rev Author # Line
23 AristotlePagaltzis 1 [Unix] systems and cousins traditionally store times as [UTC], and convert them according to the local timezone settings only for display. On a typical [Linux] machine, <tt>/etc/timezone</tt> contains the time zone (such as <tt>Pacific/Auckland</tt>), and <tt>/etc/localtime</tt> is a SymLink to a binary file containing information on the standard and the daylight savings offset of that time zone, as well instructions on how to calculate when daylight savings is in effect. In the above-mentioned example it might look like this:
15 AristotlePagaltzis 2
3 <pre>
4 __$__ ls -l /etc/localtime
5 lrwxrwxrwx 1 root root 33 Apr 22 00:19 __/etc/localtime__ -> __/usr/share/zoneinfo/Pacific/Auckland__
6 </pre>
7
21 IanMcDonald 8 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)].
15 AristotlePagaltzis 9
23 AristotlePagaltzis 10 On [Debian] systems <tt>/etc/default/rcS</tt> contains a <tt>UTC</tt> variable that decides whether or not the hardware clock is set to [UTC].
16 LawrenceDoliveiro 11
23 AristotlePagaltzis 12 On [SUSE] systems, <tt>/etc/sysconfig/clock</tt> defines a <tt>HWCLOCK</tt> variable that specifies the command-line option [hwclock(8)] for selecting the clock offset: <tt>-u</tt> for [UTC], or <tt>--localtime</tt> for local time.
16 LawrenceDoliveiro 13
23 AristotlePagaltzis 14 On [RedHat] systems, <tt>/etc/sysconfig/clock</tt> defines the <tt>UTC</tt> variable as either <tt>UTC=true</tt> if the hardware clock is in UTC, or <tt>UTC=false</tt> if it is in local time.
16 LawrenceDoliveiro 15
23 AristotlePagaltzis 16 Having the hardware clock set to [UTC] is [A Good Idea|BadIdea], 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.
15 AristotlePagaltzis 17
18 See [UTC] and [NTP] for more.
19
17 LawrenceDoliveiro 20 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.
15 AristotlePagaltzis 21
22 ----
23
24 !! How to accomplish some simple tasks
25
26 Get the Unix timestamp for the current time::
27
28 Try one of the following:
29
30 <verbatim>
31 date +%s
32 perl -e 'print time() . "\n"'
33 </verbatim>
34
35 See a human readable time for a given timestamp::
36
37 Try one of the following:
38
39 <pre>
40 date --date="1970-01-01 ''<unix timestamp>'' secs UTC"
22 JamieCurtis 41 perl -e 'print localtime( ''<unix timestamp>'' ) . "\n"'
42 perl -e 'print gmtime( ''<unix timestamp>'' ) . "\n"' # for UTC
18 LawrenceDoliveiro 43 /usr/lib/news/bin/convdate -c ''<unix timestamp>''
15 AristotlePagaltzis 44 </pre>
45
46 Convert a time in localtime to a Unix timestamp::
47
18 LawrenceDoliveiro 48 <pre>
49 /usr/lib/news/bin/convdate -n ''<date string>''
50 </pre>
51
23 AristotlePagaltzis 52 (<tt>convdate</tt> is part of the <tt>inn</tt> package.)
18 LawrenceDoliveiro 53
19 AndreasWeigel 54 Or using the date command::
55
56 <pre>
57 date --date="<date> <time> UTC" +%s
58 </pre>
59
60 Or use the mktime(3) function available in various programming languages.
15 AristotlePagaltzis 61
62 <verbatim>
63 <?php
64 $ts = mktime(11, 49, 00, 10, 17, 2004);
65 echo strftime("%Y-%m-%d %H:%M:%S %Z<br>", $ts);
66 putenv("TZ=UTC");
67 echo strftime("%Y-%m-%d %H:%M:%S %Z<br>", $ts);
68 ?>
69 </verbatim>
70
19 AndreasWeigel 71 If you run this script you'll get output like this (depending on the TimeZone of your server)
15 AristotlePagaltzis 72
73 <verbatim>
74 2004-10-17 11:49:00 NZDT
75 2004-10-16 22:49:00 UTC
76 </verbatim>
77
78 Find the current time/date for somewhere::
79
21 IanMcDonald 80 A really simple way is to set the <tt>TZ</tt> EnvironmentVariable to the timezone you're interested in, then run [date(1)]:
15 AristotlePagaltzis 81
82 <verbatim>
83 TZ=Pacific/Auckland date
84 </verbatim>
85
23 AristotlePagaltzis 86 Here the value of TZ is a filename path; if it doesn' begin with a <tt>/</tt>, then it is interpreted relative to the <tt>/usr/share/zoneinfo</tt> directory (on most Linux distros). Multiple files in this directory with the same contents give different ways of specifying the same time zone; thus <tt>NZ</tt> is a synonym for <tt>Pacific/Auckland</tt>.
18 LawrenceDoliveiro 87
23 AristotlePagaltzis 88 Note that setting <tt>TZ</tt> in this way can also be used on other commands that show dates/times, such as [ls(1)], the abovementioned <tt>perl</tt> and <tt>convdate</tt> examples etc.
15 AristotlePagaltzis 89 ----
90
91 Excerpt from comp.risks 22.94:
92
93 > 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.
94 >
95 > 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]
96 >
97 > Steve Allen writes in [http://www.ucolick.org/~sla/leapsecs/onlinebib.html] that some JDAM smart bombs and other munitions are rumored to contain these receivers. Anyone intending to use those weapons around the magic window might want to reschedule their bombing runs for some other time...
20 AlastairPorter 98
99
100 [Critical and Significant Dates|http://www.merlyn.demon.co.uk/critdate.htm] contains some interesting dates useful for testing, and also an interesting read.
24 PerryLorier 101 ----
102 !!Time Hilarity:
103 The conversion from Julian to Gregorian Calendar:
104 <verbatim>
105 $ cal 1752
106 </verbatim>
107
108 London during the blitz:
109 <verbatim>
110 $ zdump -v Europe/London | grep 194[0-9]
111 </verbatim>
15 AristotlePagaltzis 112
21 IanMcDonald 113 ----
25 AristotlePagaltzis 114 See also [NTPNotes], TimeSources
15 AristotlePagaltzis 115 ----
116 CategoryNotes