barmar@mit-eddie.UUCP (Barry Margolin) (06/23/85)
In article <143@kddlab.UUCP> asami@kddlab.UUCP (TOHRU ASAMI ) writes: >I think we have to set up a program of timezones that can cover all of >the world since it is very inconvenient to use GMT. How can you imagine >someone has to type 1:00 am when it's morning! Unfortunately, worldwide timezones contain a number of ambiguities. For instance, I believe IST is both Israel Standard Time and a time zone in Germany whose expansion I don't recall at the moment. The RFC-822 time format provides an escape for time zones not in the standard list (as it is a US DOD standard, it only contains US time zones and GMT): it defines a set of single-letter zone names, A-M (skipping I) are the zones 1-12 hour west of GMT, N-Y are the zones east of GMT, and Z, of course, is GMT (Zulu time). > {"aest", ZONE, -10 HRS}, /* Australian Eastern Time */ > {"a.e.s.t.", ZONE, -10 HRS}, > {"aesst", DAYZONE, -10 HRS}, /* Australian Eastern Summer Time */ > {"a.e.s.s.t.", DAYZONE, -10 HRS}, > {"acst", ZONE, -(9 HRS + HALFHR)}, /* Australian Central Time */ > {"a.c.s.t.", ZONE, -(9 HRS + HALFHR)}, > {"acsst", DAYZONE, -(9 HRS + HALFHR)}, /* Australian Central Summer */ > {"a.c.s.s.t.", DAYZONE, -(9 HRS + HALFHR)}, > {"awst", ZONE, -8 HRS}, /* Australian Western Time */ > {"a.w.s.t.", ZONE, -8 HRS}, /* (no daylight time there, I'm told */ > >This example also show the designer did not consider UNIX systems >used outside the US, Europe, and Australia. And maybe he didn't get that right, either. When we added Australian time zones to Multics we got the names from our Australian users, and they gave us EAST (Eastern Australian Summer (Standard?) Time, I think) and a bunch of other zones that don't look anything like the above. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
smb@ulysses.UUCP (Steven Bellovin) (06/24/85)
> >This example also show the designer did not consider UNIX systems > >used outside the US, Europe, and Australia. > > And maybe he didn't get that right, either. When we added Australian > time zones to Multics we got the names from our Australian users, and > they gave us EAST (Eastern Australian Summer (Standard?) Time, I think) > and a bunch of other zones that don't look anything like the above. > -- As I mentioned a few weeks ago, the original set of timezones in getdate() -- a routine written for different purposes entirely -- was taken from RFC733, the nearest thing to an applicable standard there was at the time. (733 was the predecessor of RFC 822, the current mail standard.) When other sites joined the net, time zones were added -- yes, I did get the list of Australian time zones from Australian users, and no, I don't know why your list was different. As for using JST in something to be transmitted -- I can't agree that that's a good idea. Nor is using Eastern Standard Time, or any other such -- if a time is to be understood, it must be unambiguous and hence absolute -- i.e., GMT. Let the local presentation software display it in any desired fashion, if you wish; maybe even keep the local time in the header as a comment -- but there is software that uses the "Date:" line, and trying to deal with all of the world's timezones just doesn't work; they're ambiguously abbreviated when looked at globally. (And that says nothing of the problems in dealing with Saudi Arabia, which -- according to the comments in ctime.c -- uses solar time.....)
mike@peregrine.UUCP (Mike Wexler) (06/27/85)
> I think we have to set up a program of timezones that can cover all of > the world since it is very inconvenient to use GMT. How can you imagine > someone has to type 1:00 am when it's morning! > > Tohru Asami > > {mcvax, hplabs, ihnp4}!kddlab!asami How about having it set up so that the Usenet software acesses a variable or define or file or something that has the Timezone initials and difference for GMT. Then you put in a conversion function that will have postnews find all things of the form NN:NN TTT where N's are digits representing hours and minutes and T's are letters representing your timezone. And it replaces these with GMT. On the output side the same conversion could be done to put things in you local time zone. -- -------------------------------------------------------------------------------- Mike Wexler(trwrb!pertec!peregrine!mike) | Send all flames to: 15530 Rockfield, Building C | trwrb!pertec!peregrine!nobody Irvine, Ca 92718 | They will then be given the (714)855-3923 | consideration they are due.
asami@kddlab.UUCP (TOHRU ASAMI ) (06/27/85)
I think the current version of timezone settings will not be
suitable for the future networks. Here I show the timezones listed
in /usr/src/lib/libc/gen/timezone.c:
-1*60, "MET", "MET DST", /* Middle European */
-2*60, "EET", "EET DST", /* Eastern European */
4*60, "AST", "ADT", /* Atlantic */
5*60, "EST", "EDT", /* Eastern */
6*60, "CST", "CDT", /* Central */
7*60, "MST", "MDT", /* Mountain */
8*60, "PST", "PDT", /* Pacific */
0, "GMT", 0, /* Greenwich */
0*60, "WET", "WET DST", /* Western European */
-10*60, "EST", "EST", /* Aust: Eastern */
-10*60+30, "CST", "CST", /* Aust: Central */
-8*60, "WST", 0, /* Aust: Western */
Here only 12 timezones are considered. I tried to put JST (Japan
Standard Time, which is -9 hours from GMT), and found it locally
works very well. However when I use JST in news or mails, every
foreign site cannot interpret JST correctly!
Here I show another example, which is listed in getdate.y in netnews:
{"nst", ZONE, 3 HRS + HALFHR}, /* Newfoundland */
{"n.s.t.", ZONE, 3 HRS + HALFHR},
{"ast", ZONE, 4 HRS}, /* Atlantic */
{"a.s.t.", ZONE, 4 HRS},
{"adt", DAYZONE, 4 HRS},
{"a.d.t.", DAYZONE, 4 HRS},
{"est", ZONE, 5 HRS}, /* Eastern */
{"e.s.t.", ZONE, 5 HRS},
{"edt", DAYZONE, 5 HRS},
{"e.d.t.", DAYZONE, 5 HRS},
{"cst", ZONE, 6 HRS}, /* Central */
{"c.s.t.", ZONE, 6 HRS},
{"cdt", DAYZONE, 6 HRS},
{"c.d.t.", DAYZONE, 6 HRS},
{"mst", ZONE, 7 HRS}, /* Mountain */
{"m.s.t.", ZONE, 7 HRS},
{"mdt", DAYZONE, 7 HRS},
{"m.d.t.", DAYZONE, 7 HRS},
{"pst", ZONE, 8 HRS}, /* Pacific */
{"p.s.t.", ZONE, 8 HRS},
{"pdt", DAYZONE, 8 HRS},
{"p.d.t.", DAYZONE, 8 HRS},
{"yst", ZONE, 9 HRS}, /* Yukon */
{"y.s.t.", ZONE, 9 HRS},
{"ydt", DAYZONE, 9 HRS},
{"y.d.t.", DAYZONE, 9 HRS},
{"hst", ZONE, 10 HRS}, /* Hawaii */
{"h.s.t.", ZONE, 10 HRS},
{"hdt", DAYZONE, 10 HRS},
{"h.d.t.", DAYZONE, 10 HRS},
{"bst", ZONE, 11 HRS}, /* Bering */
{"b.s.t.", ZONE, 11 HRS},
{"bdt", DAYZONE, 11 HRS},
{"b.d.t.", DAYZONE, 11 HRS},
{"gmt", ZONE, 0 HRS},
{"g.m.t.", ZONE, 0 HRS},
{"aest", ZONE, -10 HRS}, /* Australian Eastern Time */
{"a.e.s.t.", ZONE, -10 HRS},
{"aesst", DAYZONE, -10 HRS}, /* Australian Eastern Summer Time */
{"a.e.s.s.t.", DAYZONE, -10 HRS},
{"acst", ZONE, -(9 HRS + HALFHR)}, /* Australian Central Time */
{"a.c.s.t.", ZONE, -(9 HRS + HALFHR)},
{"acsst", DAYZONE, -(9 HRS + HALFHR)}, /* Australian Central Summer */
{"a.c.s.s.t.", DAYZONE, -(9 HRS + HALFHR)},
{"awst", ZONE, -8 HRS}, /* Australian Western Time */
{"a.w.s.t.", ZONE, -8 HRS}, /* (no daylight time there, I'm told */
This example also show the designer did not consider UNIX systems
used outside the US, Europe, and Australia.
Now USENET is spread over many contries. We have come to the point to
think about more reasonable timezone settings for the worldwide usage.
I have a watch, called "WORLD TIME", made by SEIKO. That is a small
watch. But even that small watch can display the time in any of the
following 20 cities:
City Hours From GMT
LONDON 0
PARIS,ROME -1
CAIRO -2
MOSCOW -3
DUBAI -4
KARACHI -5
DELHI -5 1/2
BANGKOK -7
HONG KONG -8
TOKYO -9
SYDNEY -10
NOUMEA -11
HONOLULU 10
LOS ANGELES 8
DENVER 7
CHICAGO 6
NEW YORK 5
CARACAS 4
RIO DE JANEIRO 3
This watch also understands in what cities the daylight saving time is
used in summer. In this meaning, a UNIX timezone database is a little bit
behind of even a small watch!
I think we have to set up a program of timezones that can cover all of
the world since it is very inconvenient to use GMT. How can you imagine
someone has to type 1:00 am when it's morning!
Tohru Asami
{mcvax, hplabs, ihnp4}!kddlab!asamichen@acf4.UUCP (H. Chen, Nick Jacobs) (07/02/85)
I must say that I agree with Mr. Asami. As part of future development of remote job processing, it will become very important for a computer to know what time it is at the computer on the other end of the line. A good discussion of internal versus external representation (as one person has already mentioned in a previous reply to Mr. Asami's note) is given in the May-June issue of American Scientist by Peter Dennings. Nicholas Jacobs !csd2!acf4!chen (Friend's acct...)