v.wales@UCLA-LOCUS.ARPA (01/28/84)
Here are several questions/comments on time zone abbreviations and
usages. I am including all of this in one message for the sake of con-
venience. Please feel free to comment on only some of what I say below,
even if you don't have anything to say about all my points.
Also, I would especially like some feedback from the people who live
(or have lived) in the areas involved, and who therefore have first-
hand knowledge.
Some of this material may seem out of place, given that we haven't been
arguing these issues lately. However, I hope that whoever out there is
planning possible future revisions of mail standards will take note of
this message and any authoritative answers it generates.
(1) It has been suggested a few times that time stamps be expressed
either in UTC or as the number of seconds past a given starting
point.
I feel, however, that such an approach would be less than ideal,
because the sender's local time of day may be a useful piece of
information for the recipient to have.
For example, suppose all "Date" lines had to show time in UTC. If
I were to send a message between 1600 and midnight (according to my
local time, PST), the "Date" line would indicate the next day, since
1600 PST = 0000 UTC. If my message's body contained a "relative"
time expression such as "today", the recipient might be confused as
to which day I meant unless he knew my physical location (and thus
my local time zone).
(Admittedly, this same problem could occur today, in cases where a
user and his computer are widely separated. However, I would assume
that the local time of the user and the computer are the same more
often than not.)
(2) People have discussed which term is "most" correct for the standard
time zone around the prime meridian -- UTC, UT, or GMT.
(a) What do the British, Irish, and whoever else falls in this time
zone call their time? (Judging from "Date" lines in messages
from UCL-CS, I would assume the answer to my question is "GMT";
however, could someone from the UK or Ireland speak up and say
definitively?)
(b) Assuming that "Date" lines are to reflect the sender's local
time, it seems wrong to make the British and Irish say "UT" or
"UTC" if their local custom is to say "GMT". If other people
somewhere want to use "UT" or "UTC", maybe the only equitable
solution is to give all three abbreviations equal status.
(c) This entire discussion becomes moot, of course, if we all end
up using numeric offsets instead of time-zone abbreviations.
(3) Would some Canadian on this list confirm or correct the following
time zone abbreviations: NST/NDT (Newfoundland); AST/ADT (Atlan-
tic); and YST/YDT (Yukon)?
Also, am I correct in assuming that the Alaskans too use YST/YDT
for Yukon time?
(4) Does Hawaii use the abbreviations HST and HDT? For that matter, do
they even have daylight savings time in Hawaii? (Hawaii's close
enough to the equator that I suppose it might not make sense for
them to use daylight savings time.)
(5) According to John Covert at DEC-Marlboro (message of 26 Jan 84),
Alaska is down to two time zones now (UTC-10 for the Aleutians and
UTC-9 for the rest of the state). Are the people in the Aleutians
going to end up calling their time zone HST/HDT (since it's the same
as Hawaii time)? Or will they use AHST/AHDT ("Alaska/Hawaii")? Or
even AST/ADT ("Alaska", or "Aleutian")?
If they decide to call it AST/ADT (and thus create a conflict with
Atlantic time), I say forget it -- the Atlantic time zone has first
dibs on the abbreviation (and more people, too!), and the Aleutians
can use a numeric offset if they don't like HST/HDT.
-- Rich <v.wales@UCLA-LOCUS>solomon@wisc-crys.ARPA (01/29/84)
This is another example of the pitfalls of confusing an interchange standard with a user-interface standard. Users would prefer to see dates in local-time format, but interchange programs would prefer something a bit more uniform and structured. If RFC 733 (and its successor, 822) had not made the mistake of defining a mail header in such a way as to make it appear to be designed to be read, the header could encode dates in any form convenient for exchange (some encoding of UT), and users who wanted to read or send mail would be FORCED to write or have written a program to translate to/from local time. (You may interpret this as a plug for the new NBS standard). By the way, in most cases, the "local time" the user would prefer to see in messages is his OWN local time. For example, when I'm reading a message from somebody and want to know whether he wrote it before or after some particular event (for example, I want to know whether he wrote it early enough that it's likely he saw a particular message from me), I'd rather see the Date line expressed in my own local time. Whenever I have to look at Received lines, I find that even to sort them in chronlogical order, I have to mentally convert to local time (or some other fixed time zone). Offhand, I cannot think of any situation where I want to see the Date line in the sender's local time, and I would argue that NOBODY wants to see maintenance timestamps (such as Received) expressed in the time zone where they were inserted.
Margulies@MIT-MULTICS.ARPA (01/29/84)
I find it helpful to get a hint of where in the world a correspondant is. The time zone does that. Further, I confess that the precise time of a message is a much better indicator of the prospective state of mind of the sender than it is anything else. I like to know that it was 9am from the senders point of view and not, for example, midnight. Finally, I think your argument is moot. pseudo-readable or not, 733 date-times are quite definitely parsable. Your user interface program is welcome to digest them and re-present hem in local time. rfc733 times are no more or less "standard", iff a reasonable set of zone appreviations is in use.
milazzo@rice.ARPA (01/30/84)
"If RFC 733 (and its successor, 822) had not made the mistake of defining a mail header in such a way as to make it appear to be designed to be read, the header could encode dates in any form convenient for exchange (some encoding of UT) [...]." It is my understanding that RFC 733 did not invent the contents of a mail header; similar formats had been in use for some time. RFC 733 simply tried to make known (and perhaps official) the various de facto standards which had sprung up in the Internet community. Thus it became a sort of "conglomerate standard". I consider this effort a noble one, if perhaps incompletely successful. Paul G. Milazzo <milazzo@rice> Dept. of Mathematical Sciences Rice University, Houston, TX
wcwells%ucbopal.CC@Berkeley.ARPA (01/31/84)
I believe we need to have two types of date-time stamps: UTC (or Z)
and local. Machine readable date-time fields of messages in transit
should be in UTC to make programming easier for mail transport
programs. The senders local time stamp could be added as a comment when
message is transmitted. Simple mailers could be required to use UTC,
more complex mail programs could do local time conversion.
Here is an example of how dates could be changed when displayed to
the user and when passed to the mail transport system:
a. Mailer/Mail composition program using local date displays:
Date: Sun, 29 Jan 84 10:03 EST
or
Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
(I prefer the latter) but transmits:
Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
to the mail transport system.
b. Relaying and receiving hosts would use only UTC at the mail
transport level. Thus with a "received" field added the header might
become:
Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21)
id AA00611; Sun, 29 Jan 84 17:53:41 utc
c. The receiver (addressee) of the message should have the option
of displaying "Date" and "Resent-Date" in either the transmittted
mail transport form:
Date: Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21)
id AA00611; Sun, 29 Jan 84 17:53:41 utc
or with the UTC part of the "Date" and "Resent-Date" changed to the
receiver's local time:
Date: Sun, 29 Jan 84 07:03 PST (Sun, 29 Jan 84 10:03 EST)
Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21)
id AA00611; Sun, 29 Jan 84 17:53:41 utc
(Note that the "received" field date-time remains in UTC. The message
should be stored in its "mail transport form".)
d. Referencing of the received message would use the full
date-time field:
In-Reply-To: Message of Sun, 29 Jan 84 15:03 UTC (Sun, 29 Jan 84 10:03 EST)
from "Benson I. Margulies" <Margulies@MIT-MULTICS.ARPA>
The nice thing about the above scheme is that only one time zone is
used at the mail transport level and we do not have to change RFC822
to implement the above since a () comment field maybe used now with any
header field.
Bill Wells
wcwells@Berkeley.ARPAwcwells%ucbopal.CC@Berkeley.ARPA (01/31/84)
It looks like UT (or maybe UTC) = GMT = GCT = Z.
Here is a reply I received from David J. Bryant via Mark Horton
<cbosgd!mark@Berkeley.ARPA>:
-------
Date: Sun, 29 Jan 84 18:56:43 est; From: mark@cbosgd.UUCP (Mark Horton)
To: wcwells@ucbopal; Subject: star gazers time
Here is an answer to your star gazers questions
Date: Sun, 29 Jan 84 18:21:08 est; From: djb (David J. Bryant)
To: mark; Subject: Re: can you please answer the "star gazers" question in this?
Astronomers time stamp observations and events according to Universal
Time (abbreviated UT). This is based on atomic clocks and mathematical
standards according to definition of the International Astromical Union
(I.A.U.). Further, Greenwich Mean Time (GMT) is defined to be the same
as UT, and applies to the standard meridian (longitude 0 degrees). Greenwich
Civil Time (GCT) is synonymous with GMT.
WWV and WBS (in England) broadcast UT (which is therefore also GMT, and
for the military, Z ("Zulu") time. This is a worldwide standard reference,
and probably the best for your purposes. (Elaine says that CompuServe
used UT for ALL their record keeping, login accounting, etc.)
There are other time schemes as follows:
Apparent Time - The time indicated by a sundial. Because the
Sun's speed across the sky is not uniform, this
varies throughout the year, and is useless for
time reckoning.
Mean Time - To avoid the non-uniformities of Apparent Time, a
fictitious "mean sun" is invoked; this moves across
the sky at a constant rate throughout the year. Mean
Time, like Apparent Time, is purely a function of your
longitude, and so is too variable for much civil use.
Civil Time - This is what the clock on the wall is set to. It
is based on the concept of Time Zones, Daylight
Saving Time, etc. Each time zone is homed on a
central meridian, and the mean time for that meridian
is used as the civil time throughout the time zone.
Other adjustments (Daylight Saving Time) apply as
required.
Sideral Time - Unlike all the above, which is based on the 24 hour
solar day, Sideral Time is based on the 23h 56min
"star" day. There are numerous flavors of Sideral
Time that compensate for variations, but I don't
see any real reason to go into much detail. This is
not a time scheme you want to use.
Interestingly, all time schemes can be converted to any other time scheme,
provided you specify latitude, date, etc.
If you would like a more thorough, informative description of these (and
other) time systems, let me know. I think this should be enough to answer
your question about "star gazing" time. Personally, I encourage you to
use UT, and to follow other standard astronomical (I.A.U.) conventions to
deal with issues associated with time/date stamping, since astronomers have
already worked out these problems.
David
-------
Now why UT and UTC? I suspect that UT is the time based on the atomic
clock from a specific point in time and that UTC is UT which has been
leap second adjusted.
Bill Wells
wcwells@Berkeley.ARPAgreep@SU-DSN.ARPA (01/31/84)
The time zone may indicate where the machine is, but that isn't necessarily the same as where the user is. For example, there is someone in Australia who uses a machine in California to send mail. More commonly, a lot of people in Washington seem to use machines at ISI to send mail. What's going to happen to time zones when we have people sending messages from Mars or manned space stations? Will they use the time zone of their country's capital?
Rick.Gumpertz@CMU-CS-A.ARPA (Richard H. Gumpertz) (02/02/84)
Parsing time zones is not hard for a computer to do. Let's not waste time on this area that works fine; instead let's fix the things that aren't easy!
wcwells%ucbopal.CC@Berkeley.ARPA (02/04/84)
On zero time zone designators:
In addition to UT, UTC, Z, and GMT, I have also heard of GCT
(C for Civil).
Z ("Zulu" or "Zero" time zone) is the military term. As far as US Armed
Forces is concerned, it is the time transmitted by the Dept. of
Commerce radios stations WWV and WWVH (hope I got the call signs
correct). WWV previously transmitted GMT time, but since the early/mid
70's has been transmitting Coordinated Universal Time(UTC). Perhaps
someone can give us some history of the name change. GMT, GCT, PST/PDT,
etc. are local Civil time designators. UT and UTC maybe defined by
international treaty/agreement (anybody know?).
I also suspect that UTC is not the same as GMT (seconds apart?).
Does any one have the name of time used by the "star gazers"?
On date/time stamping of message:
Things would be a lot easier if messages on the network would be dated
and time stamped with UTC (or "Z") time. If you want local time and
date presented/used by your users, convert the time and date in your
presentation (user interface) program(s). The military, and I think,
most international communications companies use only one time zone to
identify messages. Why can't we?
On converting UTC to/from local time:
01:00:01 01 Jan 84 UTC is 17:00:01 31 Dec 83 PST
Note the day and year difference. When converting local time to UTC,
the day and year must be converted as well. It's not hard to do. For
PST, the rule is to add 8 hours to the current time (since the sun
comes up 8 hours earlier in England than it does on the U.S. West
Coast). If the resulting hour is greater that 24, subtract 24 hours
from the hours and add 01 to the day (and add 1 to the year if the
original day is 31 Dec). (For PDT add 7 instead of 8 hours to get
UTC). I will let you figure out how to convert the other way.
New subject: When does the day change?
Or is 00:00:00 today, really 24:00:00 yesterday?
I think the military avoids the issue by never using 00:00 or 24:00
(hours and minutes) to identify messages.
Bill Wells
wcwells@Berkeley.ARPARudy.Nedved%CMU-CS-A@hou3c.UUCP (02/04/84)
Rich, I have two views of mail: 1) What you see on your screen is what is actually sent. Therefore the time zone is that time zone that you are in including daylight savings problems. If you send to another zone, you may or may not have problems but I don't see any simple solution because I feel the philosphy used by the composer and delivery agents is wrong... 2) What you see on your screen is encoded into a recusive data structure that is handled a specified way at each interface but the representation can be changed as it is moved until it reaches another software interface. The time zone should be displayed as the local time zone but stored in the encoded version as an absolute offset of GMT time. When it is displayed in the new zone, you get the readers time zone instead of the senders time zone information. The senders time zone information (offset) should be included so that some set of users can change the "local time zone" and see what time the sender sent the mail at (in case you want to know if the guy was working late before giving him a call). The RFC822/RFC733 is mostly of philosphy (1) even though I and other people at CMU wish it was different. There are just too many mail systems out in the internet that have simple/trivial mail composers/readers. I don't expect this to change given there is no motivating force that if people don't add code things do not work. I am waiting for multimedia mail and therefore philosphy (2) to happen. There however is some confusion in the world that I wish DCA or DARPA would clear up: Which multimedia specification should people follow?? I hear of one being created by DARPA, one at NBS and one at CCITT. If the issue every comes up around CMU...I am pushing for the CCITT one since Xerox has picked it and it is a more complete specification then the NBS one. -Rudy
kre@mulga.SUN (Robert Elz) (02/07/84)
For anyone that thinks that time zone names are parsable, consider that "EST" means Eastern Standard Time (Australian time that is, GMT-10) between March & October (approx), and Eastern Summer Time (that is GMT-9) between November and February. (Dates when daylight saving switches on/off are approximate, anyone interested in precise details may consult 4.2bsd libc/gen/ctime.c) For example, examine the header of this message, it should indicate that it is being sent at something like "Feb 7 00:15 EST 1984". Current time (according to "date -u") is Feb 6 13:15 GMT. A unique, unambiguous, time stamp in mail headers is really worth having. Including local time (probably best as a comment in the header, as was suggested in another item) is a good idea too, as that does have meaning, provided that you're smart enough (have enough additional knowledge) to parse it correctly. Robert Elz decvax!mulga!kre
solomon@wisc-crys.ARPA (02/07/84)
Re:
Date: Sun, 29 Jan 84 16:39:59 CST
From: Paul Milazzo <milazzo@rice>
Subject: Re: Several questions/comments on time zones
To: solomon@wisc-crys (Marvin Solomon)
Cc: header-people@mit-mc
Message-Id: <1984.01.29.16.39.59.630.00537@Rice-vms.rice>
"If RFC 733 (and its successor, 822) had not made the mistake
of defining a mail header in such a way as to make it appear to
be designed to be read, the header could encode dates in any
form convenient for exchange (some encoding of UT) [...]."
It is my understanding that RFC 733 did not invent the contents of a
mail header; similar formats had been in use for some time. RFC 733
simply tried to make known (and perhaps official) the various de facto
standards which had sprung up in the Internet community. Thus it
became a sort of "conglomerate standard". I consider this effort a
noble one, if perhaps incompletely successful.
Paul G. Milazzo <milazzo@rice>
Dept. of Mathematical Sciences
Rice University, Houston, TX
Several people have misuderstood various aspects of this comment, so
I must have not made myself clear. First, I do understand the history
of 733. One reason standards are hard to write it that you must make a choice
between two unpleasent courses: On one hand you can wait until there are
(incompatible) implementations and then try to come up with some sort of
compromise that won't break too many existing programs. On the other hand
you can try to write a spec for something that doesn't
exist yet and run the risk of specifying something that is unimplementable.
Perhaps I should have said that the choice of making headers human-readable
was "unfortunate" rather than "a mistake". Several people have pointed
out that while non-human-readable (binary) headers can only be read by
programs, human-readable (text) headers can be read by both humans AND
programs (using a little compiler technology) and thus would appear to be
preferable. My point wasn't that parsing text headers is too hard, but
rather that reading text headers is too easy, so that people tend to
write mail-reading programs that simply show the headers to users.
>From time to time, someone flames that "you wouldn't have [whatever your
favorite problem is] if you had a decent mail-reading program". If binary
headers were the standard, there would be no question but that a reasonable
mail-reading program was required, and there would be much less confusion
between trans-port level information (in both the envelope and header)
and end-user information.