bgg@pyramid.pyramid.com ( R+D Australia) (08/20/90)
There is a problem in the date handling in MH 6.7. Let me describe what happened. In Sydney, Australia, I got a message from California where the timezone in the Date: field was -0700. When I replied to this message, it changed this in the In-reply-to: field to MST. That's wrong. I presume that it did this because my machine did not have daylight saving time turned on, therefor all dates generated mustn't have daylight saving time, irrespective of where in the world they refer to. I have worked around this by commenting out all the timezone names from zones[] in zotnet/tws/dtime.c. It now gets the timezone right, albeit in numeric form. I wonder if it's possible to translate a numeric timezone to a timezone name at all reliably? Given that the dates when countries change to and from summer time vary, and ignoring the northern and southern hemispheres, the simple-minded scheme used by MH will only ever manage to get it right for messages sent and received in the same country. Further, timezone names are ambiguous, particularly in Australia. On the East Coast, the government has decreed that we use EST to mean Eastern Standard Time; in summer, we use EST to mean Eastern Summer Time. Unfortunately, EST is also used on the East Coast of the US. Numeric timezones are the only unambiguous way to print timezones. They are also easiest to use when comparing times. Can I suggest that in the next MH distribution, that the timezone names be commented out (or removed)? If people want them, they can uncomment them. Ben Golding <bgg@pta.oz.au>
jch@dyfed.rdg.dec.com (John Haxby) (08/20/90)
In article <123900@pyramid.pyramid.com>, bgg@pyramid.pyramid.com 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 > > Numeric timezones are the only unambiguous way to print timezones. > They are also easiest to use when comparing times. Can I suggest that > in the next MH distribution, that the timezone names be commented out > (or removed)? If people want them, they can uncomment them. > I agree wholehearedly, especially in the light of RFC1123. However, isn't the alpha timezone stuff controlled by the ATZ option in the MH config file? -- John Haxby Digital <jch@wessex.rdg.dec.com> Reading, England <...!ukc!wessex!jch>
kevinc@tekig5.PEN.TEK.COM (Kevin E Cosgrove) (08/20/90)
In article <123900@pyramid.pyramid.com> bgg@pyramid.pyramid.com ( R+D Australia) writes: [lots of stuff deleted] >Numeric timezones are the only unambiguous way to print timezones. >They are also easiest to use when comparing times. Can I suggest that >in the next MH distribution, that the timezone names be commented out >(or removed)? If people want them, they can uncomment them. > > Ben Golding <bgg@pta.oz.au> I agree with your problem statement, but I'd much prefer to see the code #ifdef'd rather than commented out. -- Kevin Cosgrove <kevinc@tekig5.PEN.TEK.COM>
aks@HUB.UCSB.EDU (Alan Stebbens) (08/20/90)
> [...] Can I suggest that in the next MH distribution, that the > timezone names be commented out (or removed)? If people want them, > they can uncomment them. > > Ben Golding <bgg@pta.oz.au> Well, Ben, that's really drastic -- removing, or changing the defaults to suit, albeit in a more general fashion, the constraints of using MH in Australia. My vote to the MH-maintainers is to provide timezone {names,numbers} as a configuration option, the default of which is the same as the current distribution. This way, all the folks in the US don't have to add a new config line; whereas, the Aussies can easily tailor MH to suit their needs. Oh yeah: you'll probably have to add some disambiguating code to convert incoming dates from timezone names into timezone numbers, depending upon the country of origin. It really isn't that hard to do, though. Perhaps, a motivated Aussie can come up with suitable patches?? Alan Stebbens <aks@hub.ucsb.edu> (805) 893-3221 Center for Computational Sciences and Engineering (CCSE) University of California, Santa Barbara (UCSB) 3111 Engineering I, Santa Barbara, CA 93106
bgg@pyramid.pyramid.com (Ben Golding) (08/21/90)
In article <9008201520.AA24431@somewhere> aks@HUB.UCSB.EDU (Alan Stebbens) writes: >> [...] Can I suggest that in the next MH distribution, that the >> timezone names be commented out (or removed)? If people want them, >> they can uncomment them. > >Well, Ben, that's really drastic -- removing, or changing the defaults >to suit, albeit in a more general fashion, the constraints of using MH >in Australia. You seem to have missed the point of my article. The timezone name mapping will not work twice each year for a couple of weeks on mail sent internationally (but in the same hemisphere) because of the differing dates when countries change to summer time. When mail goes between hemispheres, the code only works twice each year when the conversions overlap. So it's not surprising that the problem is more noticeable in the southern hemisphere. Basically, it's broken everywhere, not just in Australia as you implied. Assuming that all mail comes from within your country is a xenophobic attitude that is all too common in the US. John Haxby <316@hollie.rdg.dec.com> suggested that it is already controlled by the ATZ option. It's not, we have it turned off. Our options are: version: MH 6.7 #6[UCI] (pta) of Thu Jun 14 16:32:43 EST 1990 options: [BSD42] [BSD43] [FOLDPROT='"0700"'] [ISI] [LINK='"#"'] [MHE] [MHRC] [OVERHEAD] [RPATHS] [SBACKUP='"#"'] [TYPESIG='int'] [UK] [WHATNOW] [SENDMTS] [SMTP] [BPOP] [NNTP] (oh, and I did just #ifdef them out.) I believe the best solution is to put this under the control of an option in mh-config and discourage people from using it. Ben Golding <bgg@pta.oz.au>
Christopher-Vance@adfa.oz.au (08/21/90)
aks@HUB.UCSB.EDU (Alan Stebbens) writes: | Well, Ben, that's really drastic -- removing, or changing the defaults | to suit, albeit in a more general fashion, the constraints of using MH | in Australia. Or anywhere else outside USA/Canada. And there are a lot of us. | Oh yeah: you'll probably have to add some disambiguating code to convert | incoming dates from timezone names into timezone numbers, depending upon | the country of origin. It really isn't that hard to do, though. | Perhaps, a motivated Aussie can come up with suitable patches?? I get lots of mail from places which claim to use EST, but they mean +1000, not -0500. And I also get mail from other places which claim to be EST, but they mean -0500, not +1000. Now how do I disambiguate that? You want *me* to check the top-level domain of *your* machine so I know if you mean my EST or yours. Why don't *you* change *your* mail to tell me unambiguously? After all, your machine knows better than mine what your real zone is. Or you could use UTC. Or stop calling your timezone EST (yes I know where UCSB is -- I mean `your' as in USA/Canada). When you get mail from me saying my zone is EST, what are you going to do with my date? Leave it alone? Correct the zone? Misunderstand it by 15 hours? Install my code? Ignore the timezone anyway? If you don't care very must about getting the timezone right, why not put in a configuration option to omit the time zone altogether. And maybe I'll install *your* code :-). Perhaps everybody in the world can add a new TZ record type in their domain name server entries to indicate where in the world they are :-). No, it's time for an end to parochialism; let MH be defaulted to follow a reasonably useful unambiguous standard, and anyone who wants a backward-compatible, ambiguous kludge can alter his own configuration. -- Christopher
mo@messy.bellcore.com (Michael O'Dell) (08/21/90)
I think that it should use the TZ library stuff on SunOS, 4.3, and V.4, so maybe soon it will all be ok??? -Mike
ahl@technix.oz.au (Tony Landells) (08/21/90)
In article <9008201520.AA24431@somewhere> aks@HUB.UCSB.EDU (Alan Stebbens) wrote:
Well, Ben, that's really drastic -- removing, or changing the defaults
to suit, albeit in a more general fashion, the constraints of using MH
in Australia.
I can't say I agree with you at all. Ben did point out that the
problem will exist any time you go between countries with different
ideas of whether daylight savings is active or not. The worst case is
probably different hemispheres, since they'll be almost six months out
of sync., but all it takes it two places changing on different days to
cause it to manifest in the same hemisphere. And in case you STILL
haven't realised, the problem is symmetric, in that if it occurs with
US mail going to Australia, then it should also occur with the return
mail...
Oh yeah: you'll probably have to add some disambiguating code to convert
incoming dates from timezone names into timezone numbers, depending upon
the country of origin. It really isn't that hard to do, though.
Perhaps, a motivated Aussie can come up with suitable patches??
If it isn't that hard to do, I'd be pleased if you came up with the
patches, because I don't see any way you can unambiguously determine
the country of origin. To take an example I'm familiar with, HP
domain (.hp.com) encompasses the whole world (or, at least, anywhere
that HP has offices connected in some fashion to the internet), so you
can't decide from the domain. Ben has mentioned that EST is used in
both the US and Australia, so you can't use the timezone string...
I'm afraid I just can't see how one would implement this
disambiguating code: would you be so kind as to enlighten us?
Tony Landells.Makey@Logicon.COM (Jeff Makey) (08/23/90)
In article <AHL.90Aug22001059@saussure.technix.oz.au> ahl@technix.oz.au (Tony Landells) wrote: >the problem will exist any time you go between countries with different >ideas of whether daylight savings is active or not. The problem isn't limited to international mail. Not all parts of the United States observe daylight time so, for example, an offset in today's date of -0700 would indicate Pacific Daylight Time if it came from California, but if it came from Arizona the same offset would indicate Mountain Standard Time. A good way to eliminate all ambiguity would be for the sender to add a parenthesis-delimited comment to the RFC 822 Date: header, such as: Date: Wed, 22 Aug 90 15:01:57 -0700 (PDT) This provides an unambiguous, machine-parsable offset from GMT, plus a human-readable name for the time zone. There is no point in a recipient trying to second-guess the meaning of an offset or a time zone name; determining the daylight time rules for one's own location is often difficult enough without having to worry about the rest of the world. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
wisner@hayes.fai.alaska.edu (Bill Wisner) (08/23/90)
aks@HUB.UCSB.EDU (Alan Stebbens) writes: >Well, Ben, that's really drastic -- removing, or changing the defaults >to suit, albeit in a more general fashion, the constraints of using MH >in Australia. Forget Australia; MH is always telling me that I'm in the Pacific time zone. I'm not. Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775 "Early one June morning in 1872 I murdered my father--an act which made a deep impression on me at the time." -- Ambrose Bierce