Re: Time

>>[about log timestamps]
>If the timezone does not appear with the timestamp there needs to be
>some way to indicate a timezone change (EDT to EST when daylight savings
>ends for example).  Also I don't think there is an easy way to map
>the text abrevation (such as EDT) to GMT offsets, so if timezones are
>allowed I think we should specify them as an offset from GMT rather then
>text abrevations.

The question of timezone abbreviations has come up from time to time in the
context of e.g. mail and USENET news Date: headers. While I can't point at
specific references, I think it's clear that not only is there no central
list of abbreviations, there is no standardisation at all (the abbreviations
are based on whatever evolved as the names in the local language) and in
many cases the standard abbreviations are ambiguous.

For example, BST means British Summer Time to me, but the USA-originated
RFC733 mail standard (precursor to the current RFC822) defined it to mean
Bering Straits Time. That was dropped in RFC822, which recommends using
timezone offsets. I think BST may also be used in Brazil. One point I recall
from past discussions is that in some places (some Australian states?) the
abbreviation is by chance the *same* for standard and daylight-saving time,
differing only in the spelled-out versions of the name. Etc.

>Of corse if we just require the use of GMT we solve the whole problem.
>At a cost of some dirrect readability.  Which is what I would recomend.
>
>(then again if it were up to me we would be logging seconds since some
>date -- the nominal start of WWW, or the Unix epoch, or some such.

Either of those would provide the information, but having a human-readable
form can be very useful - for example, it's quite common for me to need to
search the logs based on date/time, using e.g. the UNIX grep or more
commands. A regular expression search pattern to match lines with a
timestamp between 10:00 and 10:05 is easy to type straight in; the
corresponding seconds-since-whenever is. Logs may be used for a lot more
than just retrospective analysis/reporting, and we shouldn't make a choice
that renders them impractical for those other uses.

On a related point, though it's easy to assume that (on a UNIX system at
least) you can easily convert seconds-since-epoch to local time (potentially
for any timezone you like), that's really not very reliable.

DST start/end dates in many parts of the world are set by law from year to
year, not by algorithm. I doubt a year has gone by without us seeing at
least one operating system or another make the change on the wrong date (or
need an update from the vendor to pre-empt the problem if noticed in
advance). I would be wary of relying on retrospective local-time conversions
using the zone definition information shipped with typical UNIX systems,
since it's so often been proven incorrect, and historical definitions that
didn't get fixed at the time (or only affected "irrelevant" timzones, so no
perceived need to install the fix) may well never be fixed on a particular
system.

In consequence, while GMT is the "obvious" reference point for the
timestamps, the local timezone offset is certainly needed in order that
usage reports etc., can relate reliably to the server's local time, and the
current offset definitely needs to be embedded in the logs (initially and
when it changes) in one or other of the ways people have proposed.

                                John Line
--
John Line - Cambridge University Computing Service, Computer Laboratory,
            New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Internet: jml4@cus.cam.ac.uk  Phone: +44 1223 334708

Received on Sunday, 14 April 1996 05:55:21 UTC