Differences between version 15 and predecessor to the previous major change of TimeNotes.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 15 | Last edited on Wednesday, October 12, 2005 12:26:25 am | by AristotlePagaltzis | Revert |
| Older page: | version 12 | Last edited on Tuesday, October 11, 2005 11:26:47 am | by JohnMcPherson | Revert |
@@ -1,9 +1,10 @@
[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:
-<pre>
+
+
<pre>
__$__ ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Apr 22 00:19 __/etc/localtime__ -> __/usr/share/zoneinfo/Pacific/Auckland__
-</pre>
+
</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).
On [Debian] systems __/etc/default/rcS__ contains a __UTC__ variable that decides whether or not the hardware clock is set to [UTC]. Having it that way and setting __UTC=yes__ is A Good Idea. The best reason you might want to use localtime for your hardware clock is if you dual boot with another OperatingSystem that fiddles with your hardware clock for daylight savings.
@@ -11,52 +12,67 @@
See [UTC] and [NTP] for more.
The internal representation of [UTC] time that all Unix systems use is often know 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
-<verbatim>
- date +%s
-</verbatim>
-or
-<verbatim>
- perl -e 'print time() . "\n"'
-</verbatim>
-on a Linux box to see the current Unix timestamp.
----
-<pre>
- date --date="1970-01-01 ''<unix timetamp
>'' secs UTC"
-</pre>
-or
-<pre>
-
perl -e 'print localtime( ''<unix timestamp>'' ) . "\n")
-</pre>
-or
-<pre>
-
perl -e 'print gmtime( ''<unix timestamp>'' ) . "\n") # for UTC
-</pre>
-will give you a human readable time for a given timestamp.
-----
-In PHP/C/etc you can convert
a time in localtime to a unix
timestamp using
the mktime(3) function. PHP Example below
-<verbatim>
- <?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);
- ?>
-</verbatim>
-If you run this script you'll get output like this (depending on the TimeZone of your server)
-<verbatim>
- 2004-10-17 11:49:00 NZDT
- 2004-10-16 22:49:00 UTC
-</verbatim>
-----
-A really simple way to find
the current time/date somewhere to set the TZ variable
to the timezone you're interested in and
run date(1):
-<verbatim>
- TZ=Pacific/Auckland date
-</verbatim>
+
+!! How to accomplish some simple tasks
+
+Get the Unix timestamp for the current time::
+
+ Try one of the following:
+
+ <verbatim>
+ date +%s
+ perl -e 'print time() . "\n"'
+ </verbatim>
+
+See a human readable time for a given timestamp::
+
+ 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
+
</pre>
+
+Convert
a time in localtime to a Unix
timestamp::
+
+ Use
the mktime(3) function available in various programming languages
.
+
+
<verbatim>
+
<?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);
+
?>
+
</verbatim>
+
+
If you run this script you'll get output like this (depending on the TimeZone of your server)
+
+
<verbatim>
+
2004-10-17 11:49:00 NZDT
+
2004-10-16 22:49:00 UTC
+
</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):
+
+
<verbatim>
+
TZ=Pacific/Auckland date
+
</verbatim>
+
----
-;
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]> %%% %%%
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...
+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]
+>
+
> 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...
----
CategoryNotes
