Penguin

Differences between version 23 and predecessor to the previous major change of TimeNotes.

Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History

Newer page: version 23 Last edited on Monday, May 5, 2008 4:14:19 pm by AristotlePagaltzis Revert
Older page: version 20 Last edited on Friday, April 7, 2006 9:29:28 pm by AlastairPorter Revert
@@ -1,20 +1,20 @@
-[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, __ /etc/timezone__ contains the time zone (such as __ Pacific/Auckland__ ), and __ /etc/localtime__ 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: 
+[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: 
  
  <pre> 
  __$__ ls -l /etc/localtime 
  lrwxrwxrwx 1 root root 33 Apr 22 00:19 __/etc/localtime__ -> __/usr/share/zoneinfo/Pacific/Auckland__ 
  </pre> 
  
-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(1 ) 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). 
+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 [Debian] systems __ /etc/default/rcS__ contains a __ UTC__ variable that decides whether or not the hardware clock is set to [UTC]. 
+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]. 
  
-On [SUSE] systems, __ /etc/sysconfig/clock__ defines a __ HWCLOCK__ variable that specifies the command-line option hwclock(8) for selecting the clock offset: " -u" for UTC, or " --localtime" for local time. 
+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. 
  
-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. 
+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. 
  
-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. 
+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. 
  
 See [UTC] and [NTP] for more. 
  
 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. 
@@ -37,10 +37,10 @@
  Try one of the following: 
  
  <pre> 
  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 
+ perl -e 'print localtime( ''<unix timestamp>'' ) . "\n"'  
+ perl -e 'print gmtime( ''<unix timestamp>'' ) . "\n"' # for UTC 
  /usr/lib/news/bin/convdate -c ''<unix timestamp>'' 
  </pre> 
  
 Convert a time in localtime to a Unix timestamp:: 
@@ -48,9 +48,9 @@
  <pre> 
  /usr/lib/news/bin/convdate -n ''<date string>'' 
  </pre> 
  
- (__ convdate__ is part of the __ inn__ package.) 
+ (<tt> convdate</tt> is part of the <tt> inn</tt> package.) 
  
 Or using the date command:: 
  
  <pre> 
@@ -76,17 +76,17 @@
  </verbatim> 
  
 Find the current time/date for somewhere:: 
  
- A really simple way is to set the <tt>TZ</tt> EnvironmentVariable to the timezone you're interested in, then run date(1): 
+ A really simple way is to set the <tt>TZ</tt> EnvironmentVariable to the timezone you're interested in, then run [ date(1)]
  
  <verbatim> 
  TZ=Pacific/Auckland date 
  </verbatim> 
  
-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__
+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>
  
-Note that setting __ TZ__ in this way can also be used on other commands that show dates/times, such as ls(1), the abovementioned __ perl__ and __ convdate__ examples etc. 
+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. 
 ---- 
  
 Excerpt from comp.risks 22.94: 
  
@@ -98,6 +98,8 @@
  
  
 [Critical and Significant Dates|http://www.merlyn.demon.co.uk/critdate.htm] contains some interesting dates useful for testing, and also an interesting read. 
  
+----  
+See also [NTPNotes]  
 ---- 
 CategoryNotes