eliot@jester.rtp.dg.com (Topher Eliot) (12/13/90)
Has anyone else looked into the issue of internationalizing the time/date
strings in mail headers? The X/Open conformance statement template implies
that the mail program should be modified to internationalize at least
some time and date strings, but it's not quite clear to me which. All
the uses of time and date strings that I find in our implementation of
mail end up being part of a message header.
RFC822 specifies a small number of specific strings that can be used to
described the timezone of the sender of a piece of mail, and also specifies
a set of rules for constructing strings to represent all the remaining
timezones in the rest of the world. The specific strings are the ones
us North Americans are used to: EST, EDT, CST, etc., plus GMT.
The rules are "military" (one letter, Z means GMT), and a +/-HHMM variety.
In the rules, there is no mention of daylight savings time.
The time zone database associated with the "zic" command provides named
time zones for the whole world, as best I can tell. But these names don't
meet the RFC822 spec.
So my first question is: what kind of time zone specification do folks outside
of North America expect to see on the mail they send? If I obey the
822 spec (and I feel I must), I can do one of the following:
(a) specify the time in GMT, even if the sender is in Japan;
(b) use the military rules (and baffle lots of people); or
(c) use the +/-HHMM rules (and possibly baffle people).
Is there any existing practice on this?
My second question is: what should I do about daylight savings time? If
my call to localtime() tells me that daylight savings time is in effect,
should I
(a) just ignore it,
(b) try to indicate it somehow in the date string (how?), or
(c) try to adjust the local time so that the time printed in the mail would
be accurate if DST were NOT in effect (yuck)?
By the way, I plan on sticking with English for the day and month names, as
the RFC822 is quite explicit about this.
If you reply to me I will summarize to the net. Thanks for your comments.
--
Topher Eliot
Data General Corporation eliot@dg-rtp.dg.com
62 T. W. Alexander Drive {backbone}!mcnc!rti!dg-rtp!eliot
Research Triangle Park, NC 27709 (919) 248-6371
Obviously, I speak for myself, not for DG.henry@zoo.toronto.edu (Henry Spencer) (12/14/90)
In article <1990Dec12.211026.8029@dg-rtp.dg.com> eliot@dg-rtp.dg.com writes: >... what kind of time zone specification do folks outside >of North America expect to see on the mail they send? ... All, repeat all, repeat all, times and dates in mail headers should be in GMT. The user interface should translate if appropriate -- *it* knows about arbitrarily messy local conventions. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
rickert@mp.cs.niu.edu (Neil Rickert) (12/14/90)
In article <1990Dec13.173731.531@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >All, repeat all, repeat all, times and dates in mail headers should be in >GMT. The user interface should translate if appropriate -- *it* knows >about arbitrarily messy local conventions. Well, that's a little strong. The vast majority of email stays within a single time zone, most within a single organization in that timezone, and a whole lot stays on a single machine. When you get our politicians to change to GMT for everything we can consider your radical approach. Until then most users don't want to do some arithmetic just to see when a message was sent or when it arrived. What is wrong with numeric timezones? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
barmar@think.com (Barry Margolin) (12/14/90)
In article <1990Dec13.173731.531@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >All, repeat all, repeat all, times and dates in mail headers should be in >GMT. The user interface should translate if appropriate -- *it* knows >about arbitrarily messy local conventions. One argument I've heard against this is that it is useful for the Date field to be presented in the sender's time zone. That way it is easy to tell that the reason the sender was confused is because he sent the message late at night when he was likely too tired to think clearly. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
henry@zoo.toronto.edu (Henry Spencer) (12/14/90)
In article <1990Dec13.184756.16409@Think.COM> barmar@think.com (Barry Margolin) writes: >>All, repeat all, repeat all, times and dates in mail headers should be in >>GMT. The user interface should translate... > >One argument I've heard against this is that it is useful for the Date >field to be presented in the sender's time zone. That way it is easy to >tell that the reason the sender was confused is because he sent the message >late at night when he was likely too tired to think clearly. This is useful, however, only if you know the sender well enough to assess his probable sleep cycle. I can think of a good many people, for example me, whose postings at 0200 are just fine but whose postings at 0900, if any, should be taken with a large sack of salt. However, I'll concede that including the numeric timezone is not a bad idea. (I'd still weakly favor that being an extra item of information on top of a GMT date, but that's not supported by existing format, alas.) "GMT" is the only non-numeric zone that should ever appear, though. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (12/14/90)
In article <1990Dec13.180844.15200@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>All, repeat all, repeat all, times and dates in mail headers should be in >>GMT. The user interface should translate ... > > Well, that's a little strong. The vast majority of email stays within a >single time zone, most within a single organization in that timezone, and >a whole lot stays on a single machine. When you get our politicians to >change to GMT for everything we can consider your radical approach. Until >then most users don't want to do some arithmetic just to see when a message >was sent or when it arrived. Please read what I wrote, especially the second sentence. The design of a storage/transmission format and the design of a user interface are two entirely different problems with different solutions. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
rickert@mp.cs.niu.edu (Neil Rickert) (12/14/90)
In article <1990Dec14.000511.2507@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1990Dec13.180844.15200@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>>All, repeat all, repeat all, times and dates in mail headers should be in >>>GMT. The user interface should translate ... >> >> Well, that's a little strong. The vast majority of email stays within a >>single time zone, most within a single organization in that timezone, and >>a whole lot stays on a single machine. When you get our politicians to >>change to GMT for everything we can consider your radical approach. Until >>then most users don't want to do some arithmetic just to see when a message >>was sent or when it arrived. > >Please read what I wrote, especially the second sentence. The design of >a storage/transmission format and the design of a user interface are two >entirely different problems with different solutions. I read what you said, including the second sentence. There are many user interfaces that are useful for reading mail. I count 'cat', and 'more' amongst them. And I don't think too many people will approve of 'fixing' these to convert dates. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
dik@cwi.nl (Dik T. Winter) (12/14/90)
In article <1990Dec13.184756.16409@Think.COM> barmar@think.com (Barry Margolin) writes: > One argument I've heard against this is that it is useful for the Date > field to be presented in the sender's time zone. That way it is easy to > tell that the reason the sender was confused is because he sent the message > late at night when he was likely too tired to think clearly. I second this (please note the time stamp of this message; it is already quite late overhere). :-) -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
dik@cwi.nl (Dik T. Winter) (12/14/90)
In article <2686@charon.cwi.nl> dik@cwi.nl (I) write: > I second this (please note the time stamp of this message; it is already > quite late overhere). :-) And you thought it was only 1:50 AM? You were wrong; our timezone is GMT+1. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
karish@mindcraft.com (Chuck Karish) (12/14/90)
In article <1990Dec14.004807.10995@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <1990Dec14.000511.2507@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: [ Mail headers should express the time in GMT. User interfaces may translate this to local time. ] > I read what you said, including the second sentence. There are many user >interfaces that are useful for reading mail. I count 'cat', and 'more' >amongst them. And I don't think too many people will approve of 'fixing' >these to convert dates. The Real Programmers who use dd to read mail and news can't calculate local time from GMT? And we should add cruft to the data stream to accomodate them? No, thanks. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
AMillar@cup.portal.com (Alan DI Millar) (12/14/90)
Here's my personal opinion for what it is worth. I like the headers that use the numeric offset with a description in parentheses, such as: Date: 14 Jun 1990 11:23:35 -0800 (PDT) Another alternative which I have not seen but might be nice is: Date: 14 Dec 1990 11:23:35 -0700 (Pacific Std Time) Either way it can be easily read (comments) and easily processed (numbers). And don't forget: the RFCs now state that four-digit years are acceptable. Better fix the software now. (I tell you, I'm getting out of computing by 1999 when all the world's stupid two-digit date software explodes :-) - Alan Millar AMillar@cup.portal.com
scs@lokkur.dexter.mi.us (Steve Simmons) (12/14/90)
rickert@mp.cs.niu.edu (Neil Rickert) writes: > I read what you said, including the second sentence. There are many user >interfaces that are useful for reading mail. I count 'cat', and 'more' >amongst them. And I don't think too many people will approve of 'fixing' >these to convert dates. Best joke I've heard all day. `We're going to keep all timestamps in local zone so our readers can use cat to read mail and not have to think about how to convert from GMT.' Oh yeah, you can read raw mailboxes with cat and more. `Possible', yes. Useful? Not compared to a real user mail agent. To do a reducto ad absurdum, ingres should be modified to keep data in ASCII with tags, so we can read it with cat. :-) If somebody wants to read the raw bits, we're under no obligation to make it simpler for them. Using a GMT and offset makes it easier on the rest the software in the world. User mail agents can't and shouldn't be expected to know every nook and cranny of time conventions. -- "SO be it! The fate of the UNIVERSE is in your hands!" "Talk about job-related stress."
rickert@mp.cs.niu.edu (Neil Rickert) (12/14/90)
In article <1990Dec14.130316.21515@lokkur.dexter.mi.us> scs@lokkur.dexter.mi.us (Steve Simmons) writes: >rickert@mp.cs.niu.edu (Neil Rickert) writes: > >> I read what you said, including the second sentence. There are many user >>interfaces that are useful for reading mail. I count 'cat', and 'more' >>amongst them. And I don't think too many people will approve of 'fixing' >>these to convert dates. > >Best joke I've heard all day. `We're going to keep all timestamps in >local zone so our readers can use cat to read mail and not have to >think about how to convert from GMT.' Oh yeah, you can read raw OK. Let me make my point a little clearer. Mail headers are often inserted into the body of other mail messages. Sometimes they appear plain, sometimes offset with white space, sometimes with a character such as '>' or '|'. Will your smart MUA present all the times in these included headers optionally in the timezone of the sender of the original mail (not the current message) or the local timezone, which ever the mail reader prefers? And if headers are only in GMT how can the MUA even find out the time zone of the sender? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
nazgul@alphalpha.com (Kee Hinckley) (12/14/90)
In article <1990Dec14.004807.10995@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > I read what you said, including the second sentence. There are many user >interfaces that are useful for reading mail. I count 'cat', and 'more' >amongst them. And I don't think too many people will approve of 'fixing' >these to convert dates. Those will be real useful when I send you a message with a Fax and some voice annotations in it. I don't buy the argument that you don't feel like converting dates in your head but you're happy reading your mail with cat. I'd rather have the date in a reliably machine readable form - my UA converts it to human readable. -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
henry@zoo.toronto.edu (Henry Spencer) (12/15/90)
In article <1990Dec14.004807.10995@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > [date conversion in user interface] ... There are many user >interfaces that are useful for reading mail. I count 'cat', and 'more' >amongst them... "cat" and the like were useful user interfaces in the days of UUCP mail, but the advent of RFC822 headers has made them almost useless, given the screenful or two of sludge one has to wade through before getting to any useful information. It takes a more intelligent interface just to pick the tidbits of significant data out of those kilobytes of garbage; such an interface can easily do date conversion. -- "The average pointer, statistically, |Henry Spencer at U of Toronto Zoology points somewhere in X." -Hugh Redelmeier| henry@zoo.toronto.edu utzoo!henry
yfcw14@castle.ed.ac.uk (K P Donnelly) (12/15/90)
Isn't the sign convention in numeric dates rather unfortunate?
e.g. If a mail message arives with time stamp
07:34:02 -0500
this means that it was sent at
07:34:02 +05:00:00 = 11:34:02 GMT (or "Universal Time")
and *not* at
07:34:02 -05:00:00 = 02:34:02 GMT
Kevin Donnellykeld@login.dkuug.dk (Keld J|rn Simonsen) (12/15/90)
Why don't we do like sendmail has done it for ages? Write "GMT+2" for somebody (like me and most of other western European people) being two hours ahead of GMT. Thus you have the locale timezone and an easily parsable universal time. Sendmail also timestamps its messageid with the GMT (+0) time. Well, then it is not GMT anymore, but UTC... Keld Simonsen
nazgul@alphalpha.com (Kee Hinckley) (12/16/90)
In article <keld.661207816@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: >Why don't we do like sendmail has done it for ages? >Write "GMT+2" for somebody (like me and most of other western >European people) being two hours ahead of GMT. What do you do for places where the timezone bumps by less than an hour (I hear Saudia Arabia does it in minutes). -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
eliot@jester.rtp.dg.com (Topher Eliot) (12/19/90)
In article <1990Dec15.180350.5920@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes: |> In article <keld.661207816@dkuugin> keld@login.dkuug.dk (Keld J|rn Simonsen) writes: |> >Why don't we do like sendmail has done it for ages? |> >Write "GMT+2" for somebody (like me and most of other western |> >European people) being two hours ahead of GMT. |> What do you do for places where the timezone bumps by less than |> an hour (I hear Saudia Arabia does it in minutes). For what it's worth, "GMT+2" doesn't meet the RFC 822 specification. "+0200" does. So does "+0032", if that's what you want. Someone else said: |>Here's my personal opinion for what it is worth. I like the headers |>that use the numeric offset with a description in parentheses, such as: |>Date: 14 Jun 1990 11:23:35 -0800 (PDT) |>Another alternative which I have not seen but might be nice is: |>Date: 14 Dec 1990 11:23:35 -0700 (Pacific Std Time) I basically agree with this, but watch out for time zone names that contain characters with the high bit on! I don't know that any are in use, but as far as I know, there's nothing in the (other) time zone mechanisms to prevent them from being created. -- Topher Eliot Data General Corporation eliot@dg-rtp.dg.com 62 T. W. Alexander Drive {backbone}!mcnc!rti!dg-rtp!eliot Research Triangle Park, NC 27709 (919) 248-6371 Obviously, I speak for myself, not for DG.
enag@ifi.uio.no (Erik Naggum) (12/19/90)
In article <1990Dec18.163218.938@dg-rtp.dg.com>, Topher Eliot writes:
I basically agree with this, but watch out for time zone names that contain
characters with the high bit on! I don't know that any are in use, but
as far as I know, there's nothing in the (other) time zone mechanisms to
prevent them from being created.
Except that RFC 822 and 821 specify that Internet mail is 7-bit, only.
--
[Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions. Wail: +47-2-836-863 Another int'l standards dude.shawn@marilyn.UUCP (Shawn P. Stanley) (12/19/90)
In article <7590@castle.ed.ac.uk> yfcw14@castle.ed.ac.uk (K P Donnelly) writes: >Isn't the sign convention in numeric dates rather unfortunate? >e.g. If a mail message arives with time stamp > 07:34:02 -0500 >this means that it was sent at > 07:34:02 +05:00:00 = 11:34:02 GMT (or "Universal Time") Depends on your point of view. Don't look at it as subtracting from the time; think of it as subtracting from GMT to achieve that time. -- Shawn P. Stanley shawn@marilyn.marilyn.mn.org tcnet!marilyn!shawn {rosevax,crash}!orbit!marilyn!shawn
guy@auspex.auspex.com (Guy Harris) (12/20/90)
>Until then most users don't want to do some arithmetic just to see when >a message was sent or when it arrived. To quote from the message to which you're responding: >The user interface should translate if appropriate -- *it* knows >about arbitrarily messy local conventions. so Henry was not saying that users should have to "do some arithmetic just to see when a message was sent or when it arrived". He was saying that the *user agent* should do that arithmetic. Unfortunately, many user agents don't do so, so the question is how quickly they'd get updated to do so (or how quickly those that don't would be discarded) if lots of messages started having header times in GMT. If it happens quickly enough, no problem; if it doesn't, such that the effect of going to GMT is that users *do* end up having to do that arithmetic, the proposal may well not really make life better for the end user. (An unfortunately tendency, at times, is to contrast alternatives A and B under the assumption that some C could exist that makes one of the alternatives better, when that C doesn't, in fact, exist yet; a bird in the hand is worth two in the bush.)
sommar@enea.se (Erland Sommarskog) (12/26/90)
Also sprach Erik Naggum (enag@ifi.uio.no): >Topher Eliot writes: > I basically agree with this, but watch out for time zone names that contain > characters with the high bit on! I don't know that any are in use, but > as far as I know, there's nothing in the (other) time zone mechanisms to > prevent them from being created. > >Except that RFC 822 and 821 specify that Internet mail is 7-bit, only. Which opens for the question: when will they be replaced by specifications that leaves room for 8-bit characters? Having spent of my working days the last two and half years in an eight-bit environment (VMS), coming home to Unix and seven-bit has a flavour of antiqueness of it. Of course it would be even better if Internet mail and similar were upgraded to be capable to handle ISO 10646 as well, if we forget that 10646 is only in DIS stage this far. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se "There is only one success, namely to lead your life in your own way" Anyone who can give a source for this?
dlv@cunyvms1.gc.cuny.edu (Dimitri Vulis, CUNY GC Math) (12/28/90)
Erland, et al: Many flavors of Unix are becoming "internationalized" (i.e., accept 8-bit in vi, et al). Many folks (including myself) feel that 10646 is a bad DIS. There is, however, a 16-bit proposal known as Unicode. I'd like to see a Unix that handles 16-bit text well! :) happy n.y. from n.y. Dimitri Vulis BITNET: DLV@CUNYVMS1 Internet: DLV@CUNYVMS1.GC.CUNY.EDU Snail mail: Department of Mathematics/Box 330 City Univesrity of New York Graduate Center 33 W 42 St