jef@well.UUCP (Jef Poskanzer) (11/29/89)
I'll be posting patches to add a checksum header sometime soon, but
meanwhile here's something else to discuss. News articles currently
put GMT in the "Date:" header. This may even be required by the news
RFC, I don't know. It is obviously not required by the mail RFC that
the news one is built on. But RFC or no RFC, it seems to me that it
would be better if the date were in the local time at the originating
machine. The reasoning is twofold:
1) It's easy to go from local times to GMT, but it's impossible to go
from GMT to the appropriate local time since you don't know which one
is appropriate. Thus if people started posting in local time but someone
absolutely had to see GMT, he could easily modify his newsreaders to
parse the date field and convert. In other words, it doesn't break
anything (too badly).
2) Displaying the time in GMT is of limited utility - the only reason
for it that I can think of is to enable a human to tell the posting
order of a set of messages, but who does that kind of thing manually?
On the other hand, displaying local time would be very useful. In
local-distribution newsgroups, there is no reason to use anything
else. In world-wide newsgroups, local time might tell you that a
message was posted at 4 in the morning, explaining its lack of
coherence.
Am I missing anything, or should I go ahead and post the patches?
Just as with checksumming, I expect this to be completely optional.
---
Jef
Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef
"Faith: not *wanting* to know what is true." -- Friedrich NietzscheMakey@LOGICON.ARPA (Jeff Makey) (11/29/89)
Rather than make a change that will very likely break someone's news
software, somewhere, it would make a lot more sense to simply modify
your favorite newsreader program to convert GMT to local time before
displaying it (I would be interested in such a patch to rn, in fact).
I admit this is more difficult to do, but it is consistent with the
Principle of Least Astonishment. I'll bet that the RFC requires GMT,
anyway.
The folks who have brought us the Network Time Protocol (NTP) are
stronly convinced that GMT is the only sensible thing to exchange
between systems. I think it has something to do with the fact that
it's much easier to deal with only your local conversion to/from GMT
than to also deal with all of the other wacko conversions used around
the world.
:: Jeff Makey
Department of Tautological Pleonasms and Superfluous Redundancies Department
Disclaimer: Logicon doesn't even know we're running news.
Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makeyjef@well.UUCP (Jef Poskanzer) (11/29/89)
In the referenced message, Makey@LOGICON.ARPA (Jeff Makey) wrote: }Rather than make a change that will very likely break someone's news }software, somewhere, Where? Can you come up with an example? } it would make a lot more sense to simply modify }your favorite newsreader program to convert GMT to local time before }displaying it. I admit this is more difficult to do, It's not merely difficult, it's impossible. The information isn't there. Remember, we are talking about local time at the sender, not the reader. }I'll bet that the RFC requires GMT, anyway. Does it? And if it does, does it matter? --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "The Russians' predisposition for quiet reflection followed by sudden preventive action explains why they led the field for many years in both chess and axe murders." -- Marshall Brickman
amanda@intercon.com (Amanda Walker) (11/29/89)
In article <14749@well.UUCP>, jef@well.UUCP (Jef Poskanzer) writes: > 1) It's easy to go from local times to GMT, but it's impossible to go > from GMT to the appropriate local time since you don't know which one > is appropriate. You could always add an X-header that has the latitude and longitude of the machine you're posting from. A precision of 1 arc second would probably be good enough for most purposes, although you might want an altitude as well, so as to be able to discriminate between floors of a building. I've actually though of doing this, although mostly as a joke :-). -- Amanda Walker InterCon Systems Corporation amanda@intercon.com
henry@utzoo.uucp (Henry Spencer) (11/29/89)
In article <14749@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: >... News articles currently >put GMT in the "Date:" header. This may even be required by the news >RFC, I don't know... It is not required but is *strongly* recommended. The problem is that there are many different ways of expressing what time zone the date was written in, and some of them are ambiguous. (For example, BST is both British Summer Time and Bering Standard Time.) Life is much, much simpler if dates are interchanged in a single common representation -- GMT -- and the conversion is done by the news readers when they display the date. Then any bizarre eccentricities of a site are confined to that site. Believe me, this is the best approach. The other was tried, in the beginning, and found to be an endless source of trouble. The Date header is not broken. Please do not fix it. -- That's not a joke, that's | Henry Spencer at U of Toronto Zoology NASA. -Nick Szabo | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
rsalz@bbn.com (Rich Salz) (11/29/89)
In <14749@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: > it seems to me that it >would be better if the date were in the local time at the originating >machine. I disagree. At least with dates in GMT, I just have to learn one simple rule -- subtract five hours to get the "real" time. I need to look at a globe whenever someone mentions the international date line. Dealing with "X" foreign times is much too complicated. What do you think is the benefit? >1) It's easy to go from local times to GMT, but it's impossible to go >from GMT to the appropriate local time since you don't know which one >is appropriate. Thus if people started posting in local time but someone >absolutely had to see GMT, he could easily modify his newsreaders to >parse the date field and convert. This seems self-contradictory. You can't do GMT->foreign local because you don't know the rules, but you can do foreign local->GMT? I don't think time converstions work that way. Am I just confused? I think the thing that makes the most sense is to display dates in local time at the reading machine. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
Makey@LOGICON.ARPA (Jeff Makey) (11/29/89)
In article <14752@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: >In the referenced message, Makey@LOGICON.ARPA (Jeff Makey) wrote: >}I'll bet that the RFC requires GMT, anyway. > >Does it? And if it does, does it matter? I looked, and section 2.1.2 of RFC 1036 says: There is no hope of having a complete list of timezones. Universal Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST, CDT, EST, EDT) and the +/-hhmm offset specifed in RFC-822 should be supported. It is recommended that times in message headers be transmitted in GMT and displayed in the local time zone. I suggest you read the rest of the section yourself before you unleash your patches. The answer is no, the RFC doesn't *require* the date to be in GMT. But even if it did, we all know that it only causes problems when everybody follows a standard so it's best to invent your own way of doing things [is there a smiley-like symbol to indicate sarcasm?]. Still, I couldn't care less what the sender's local time was when the article was posted. I would much rather have the date displayed in *my* local time by my newsreader, and putting anything but GMT in the Date: header line is guaranteed to make that job more difficult. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
jef@ace.ee.lbl.gov (Jef Poskanzer) (11/29/89)
In the referenced message, rsalz@bbn.com (Rich Salz) wrote: }This seems self-contradictory. You can't do GMT->foreign local }because you don't know the rules, but you can do foreign local->GMT? }I don't think time converstions work that way. Am I just confused? You're confused. You can't do GMT->foreign local time not because you don't know the rules, but because you don't know what time zone the message came from. The information isn't there. However, Henry's objection makes more sense. I wasn't aware that time zone notation was not standardized. That's rather unfortunate, and I agree that it blows this scheme out of the water. }I think the thing that makes the most sense is to display dates in }local time at the reading machine. This sounds like a useful option to add to a newsreader, but I'm not interested in adding it. The best compromise from my point of view might be to generate and look for an "X-Local-Date:" header. Anyone see any problems with this? --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "To err is human. To blame it on someone else is politics." -- Hubert H. Humphrey
gwollman@jhunix.HCF.JHU.EDU (Garrett A Wollman) (11/29/89)
People have said that all news articles should be passed in GMT. Other people want to see them in local time. How about a non-lethal compromise.... Define an X-Timezone header, which would give the timezone in which the sender is located, in terms of minutes east of Greenwich. Then people who like to see local time can have their newsreaders automatically adjust the time to local time. This is, of course, assuming that people have X-headers in their weed-out lists. -GAWollman
cathyf@rice.edu (Catherine A. Foulston) (11/29/89)
In article <581@logicon.arpa> Makey@LOGICON.ARPA (Jeff Makey) writes: >I looked, and section 2.1.2 of RFC 1036 says: > [...] It is recommended that times in message headers be > transmitted in GMT and displayed in the local time zone. >Still, I couldn't care less what the sender's local time was when the >article was posted. I would much rather have the date displayed in >*my* local time by my newsreader, and putting anything but GMT in >the Date: header line is guaranteed to make that job more difficult. > > :: Jeff Makey I agree with this completely. I have sometimes wanted to know _how long ago_ an article was posted, but rarely what the local time was. And for transmission it seems best to adhere to a well-defined standard. Since I keep forgetting how many hours to add/subtract for GMT, and most of our users shouldn't have to know, the easiest way to deal with this would be to display all times in the reader's local time. Does anyone know a simple way to make rn do this? I've been asked to do this anyway, since we have local newsgroups which carry system announcements, coursework due date changes, and so forth. GMT is really inappropriate for these groups. I was hoping there was a compile-time option for this in rn, but if there is, I missed it. So if I don't hear of any patches for this, I'll probably try to fix it myself over winter break. I'll post patches if I get it done. Cathy Foulston =||= cathyf@rice.edu =||= {well-connected}!rice!cathyf
brian@ucsd.Edu (Brian Kantor) (11/30/89)
If you want to do this in a sane a logical way, do this: Date: whatever it is in GMT X-Localtime-Offset: -0800 So to get the local time at which that article was posted, add -8 hours to the GMT time. That solves ALL the problems, since the poster is supplying his local time offset and YOU can then see the timestamp on the article in GMT, his time, or your time. It even handles those bizarre places that are n.5 hours off GMT. You could just include it after the date on the same line, if you wish. e.g., Date: 29 Nov 89 12:53:48 GMT -0800 - Brian
Makey@LOGICON.ARPA (Jeff Makey) (11/30/89)
In article <4309@helios.ee.lbl.gov> Jef Poskanzer <jef@well.sf.ca.us> writes: >The best compromise from my point of view might be to generate and look >for an "X-Local-Date:" header. Anyone see any problems with this? Yes. It wastes disk space, CPU time, and transmission bandwidth on a feature in which nobody seems to be interested but you. I realize that I can't stop you from adding such a feature to your own news software, but I'm sure you realize that it won't do you a whole lot of good unless many other sites implement it. Fortunately (from my perspective) it doesn't look like that will happen. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: Logicon doesn't even know we're running news. Internet: Makey@LOGICON.ARPA UUCP: {nosc,ucsd}!logicon.arpa!Makey
allbery@NCoast.ORG (Brandon S. Allbery) (11/30/89)
As quoted from <2184@coconut.bbn.com> by rsalz@bbn.com (Rich Salz): +--------------- | In <14749@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: | >1) It's easy to go from local times to GMT, but it's impossible to go | >from GMT to the appropriate local time since you don't know which one | >is appropriate. Thus if people started posting in local time but someone | >absolutely had to see GMT, he could easily modify his newsreaders to | >parse the date field and convert. | | This seems self-contradictory. You can't do GMT->foreign local | because you don't know the rules, but you can do foreign local->GMT? | I don't think time converstions work that way. Am I just confused? +--------------- The local posting time contains the timezone, which is sufficient information to compute GMT. A GMT posting time contains *no* local timezone information, so you have to try to infer the timezone from the poster's location... assuming you can get *that* information. However, I agree that there is little incentive aside from the somewhat frivolous desire to attempt to graph the (in-)coherence of a posting against the poster's local time. ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.
henry@utzoo.uucp (Henry Spencer) (11/30/89)
In article <10226@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes: >You could just include it after the date on the same line, if you wish. >e.g., > Date: 29 Nov 89 12:53:48 GMT -0800 No, you couldn't -- this breaks getdate(), and RFC1036 requires that dates be acceptable to getdate(). -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jef@surf.ee.lbl.gov (Jef Poskanzer) (11/30/89)
Ok, appended is a shar containing two independent sets of context diffs.
The first, inews.diffs, modifies B inews so that it adds the X-Local-Date
header to locally-posted articles. The timezone stuff may not be
portable - let me know if there are problems.
The second, rn.diffs, modifies rn so that if the -Hx-local-date flag is
set, the X-Local-Date header is used in preference to the Date header.
If X-Local-Date does get used, it comes out as "Date". And the 'v'
command is handled correctly.
I was surprised at how small the necessary changes were.
---
Jef
Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef
Baby on board.
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# inews.diffs
# rn.diffs
# This archive created: Wed Nov 29 21:59:39 1989
# By: Jef Poskanzer
export PATH; PATH=/bin:$PATH
echo shar: extracting "'inews.diffs'" '(4845 characters)'
if test -f 'inews.diffs'
then
echo shar: will not over-write existing file "'inews.diffs'"
else
sed 's/^X//' << \SHAR_EOF > 'inews.diffs'
XContext diffs of Makefile.dst, header.c, funcs2.c, and rfc822.c:
X
X*** /tmp/,RCSt1a05961 Wed Nov 29 21:42:13 1989
X--- Makefile.dst Wed Nov 29 20:39:24 1989
X***************
X*** 38,43 ****
X--- 38,44 ----
X #VMS LNRNEWS = cp # No links in Eunice
X DEBUG =
X SCCSID = -DSCCSID
X+ LOCALDATE = -DLOCALDATE
X
X #NNTP SERVER= -DSERVER -I$(NNTPDIR)/common
X
X***************
X*** 69,79 ****
X #BSD4_3 VFORK=
X
X #USG IBMFLAGS =
X! #USG CFLAGS = ${DEBUG} -O $(IBMFLAGS) -DUSG -Dindex=strchr -Drindex=strrchr ${DEFS} ${SCCSID} ${VFORK} ${NETINCLUDE}
X #USG LFLAGS = ${DEBUG} -s -i $(IBMFLAGS)
X #USG LIBS =
X #USG LINTFLAGS = -DUSG ${DEFS} ${NETINCLUDE}
X! #V7 CFLAGS = ${DEBUG} -DDBM ${DEFS} ${SCCSID} ${VFORK} ${NETINCLUDE}
X #V7 LFLAGS = ${DEBUG}
X #V7 LIBS = -ldbm
X #V7 LINTFLAGS = -chba -DDBM ${DEFS} ${NETINCLUDE}
X--- 70,80 ----
X #BSD4_3 VFORK=
X
X #USG IBMFLAGS =
X! #USG CFLAGS = ${DEBUG} -O $(IBMFLAGS) -DUSG -Dindex=strchr -Drindex=strrchr ${DEFS} ${SCCSID} ${LOCALDATE} ${VFORK} ${NETINCLUDE}
X #USG LFLAGS = ${DEBUG} -s -i $(IBMFLAGS)
X #USG LIBS =
X #USG LINTFLAGS = -DUSG ${DEFS} ${NETINCLUDE}
X! #V7 CFLAGS = ${DEBUG} -DDBM ${DEFS} ${SCCSID} ${LOCALDATE} ${VFORK} ${NETINCLUDE}
X #V7 LFLAGS = ${DEBUG}
X #V7 LIBS = -ldbm
X #V7 LINTFLAGS = -chba -DDBM ${DEFS} ${NETINCLUDE}
X***************
X*** 87,93 ****
X
X #VMS TERMLIB = -ltrmlib
X #VMS LIBS = -ldbm
X! #VMS CFLAGS = ${DEBUG} -O -DDBM ${DEFS} -DVMS ${SCCSID} ${VFORK}
X #VMS MISC = uname.o
X #VMS LINTFLAGS = -chba -DDBM -DVMS ${DEFS}
X #VMS VFORK=
X--- 88,94 ----
X
X #VMS TERMLIB = -ltrmlib
X #VMS LIBS = -ldbm
X! #VMS CFLAGS = ${DEBUG} -O -DDBM ${DEFS} -DVMS ${SCCSID} ${LOCALDATE} ${VFORK}
X #VMS MISC = uname.o
X #VMS LINTFLAGS = -chba -DDBM -DVMS ${DEFS}
X #VMS VFORK=
X*** /tmp/,RCSt1a05961 Wed Nov 29 21:42:17 1989
X--- header.c Wed Nov 29 21:28:45 1989
X***************
X*** 656,665 ****
X fprintf(fp, "Keywords: %s\n", hp->keywords);
X fprintf(fp, "Message-ID: %s\n", hp->ident);
X t = cgtdate(hp->subdate);
X- fprintf(fp, "Date: %s\n", arpadate(&t));
X #ifdef LOCALDATE
X fprintf(fp, "X-Local-Date: %s\n", localarpadate(&t));
X #endif /* LOCALDATE */
X #ifdef OLD
X fprintf(fp, "Article-I.D.: %s\n", oident(hp->ident));
X fprintf(fp, "Posted: %s", ctime(&t));
X--- 656,665 ----
X fprintf(fp, "Keywords: %s\n", hp->keywords);
X fprintf(fp, "Message-ID: %s\n", hp->ident);
X t = cgtdate(hp->subdate);
X #ifdef LOCALDATE
X fprintf(fp, "X-Local-Date: %s\n", localarpadate(&t));
X #endif /* LOCALDATE */
X+ fprintf(fp, "Date: %s\n", arpadate(&t));
X #ifdef OLD
X fprintf(fp, "Article-I.D.: %s\n", oident(hp->ident));
X fprintf(fp, "Posted: %s", ctime(&t));
X*** /tmp/,RCSt1a05961 Wed Nov 29 21:42:24 1989
X--- funcs2.c Wed Nov 29 20:39:28 1989
X***************
X*** 325,330 ****
X--- 325,394 ----
X return b;
X }
X
X+ #ifdef LOCALDATE
X+ /*
X+ * localarpadate is like arpadate except that it produces local time
X+ * instead of GMT.
X+ */
X+ char *
X+ localarpadate(longtime)
X+ time_t *longtime;
X+ {
X+ register char *p, *q, *ud;
X+ register int i;
X+ static char b[40];
X+ struct timeval tv;
X+ struct timezone tz;
X+ struct tm *tp;
X+ char *tzn;
X+ extern struct tm *localtime();
X+ extern char *asctime(), *timezone();
X+
X+ /* Get current time. This will be used resolve the timezone. */
X+ gettimeofday(&tv, &tz);
X+ tp = localtime(longtime);
X+ ud = asctime(tp);
X+
X+ /* Crack the UNIX date line in a singularly unoriginal way. */
X+ q = b;
X+
X+ #ifdef notdef
X+ /* until every site installs the fix to getdate.y, the day
X+ of the week can cause time warps */
X+ p = &ud[0]; /* Mon */
X+ *q++ = *p++;
X+ *q++ = *p++;
X+ *q++ = *p++;
X+ *q++ = ','; *q++ = ' ';
X+ #endif
X+
X+ p = &ud[8]; /* 16 */
X+ if (*p == ' ')
X+ p++;
X+ else
X+ *q++ = *p++;
X+ *q++ = *p++; *q++ = ' ';
X+
X+ p = &ud[4]; /* Sep */
X+ *q++ = *p++; *q++ = *p++; *q++ = *p++; *q++ = ' ';
X+
X+ p = &ud[22]; /* 1979 */
X+ *q++ = *p++; *q++ = *p++; *q++ = ' ';
X+
X+ p = &ud[11]; /* 01:03:52 */
X+ for (i = 8; i > 0; i--)
X+ *q++ = *p++;
X+
X+ tzn = timezone(tz.tz_minuteswest, tp->tm_isdst);
X+ *q++ = ' ';
X+ do {
X+ *q++ = *tzn;
X+ } while ( *tzn++ != '\0' );
X+
X+ return b;
X+ }
X+ #endif /* LOCALDATE */
X+
X char *
X replyname(hptr)
X struct hbuf *hptr;
X*** /tmp/,RCSt1a05961 Wed Nov 29 21:42:28 1989
X--- rfc822.c Wed Nov 29 21:28:50 1989
X***************
X*** 262,271 ****
X }
X } else {
X time(&t);
X- fprintf(fp, "Date: %s\n", arpadate(&t));
X #ifdef LOCALDATE
X fprintf(fp, "X-Local-Date: %s\n", localarpadate(&t));
X #endif /* LOCALDATE */
X }
X if (*hp->expdate)
X fprintf(fp, "Expires: %s\n", hp->expdate);
X--- 262,271 ----
X }
X } else {
X time(&t);
X #ifdef LOCALDATE
X fprintf(fp, "X-Local-Date: %s\n", localarpadate(&t));
X #endif /* LOCALDATE */
X+ fprintf(fp, "Date: %s\n", arpadate(&t));
X }
X if (*hp->expdate)
X fprintf(fp, "Expires: %s\n", hp->expdate);
SHAR_EOF
if test 4845 -ne "`wc -c < 'inews.diffs'`"
then
echo shar: error transmitting "'inews.diffs'" '(should have been 4845 characters)'
fi
fi # end of overwriting check
echo shar: extracting "'rn.diffs'" '(2196 characters)'
if test -f 'rn.diffs'
then
echo shar: will not over-write existing file "'rn.diffs'"
else
sed 's/^X//' << \SHAR_EOF > 'rn.diffs'
XContext diffs of head.h and art.c:
X
X*** /tmp/,RCSt1a06028 Wed Nov 29 21:53:06 1989
X--- head.h Wed Nov 29 21:34:11 1989
X***************
X*** 43,50 ****
X #define SUMRY_LINE 24 /* summary */
X #define SUBJ_LINE 25 /* subject */
X #define XREF_LINE 26 /* xref */
X
X! #define HEAD_LAST 27 /* one more than the last one above */
X
X struct headtype {
X char *ht_name; /* header line identifier */
X--- 46,54 ----
X #define SUMRY_LINE 24 /* summary */
X #define SUBJ_LINE 25 /* subject */
X #define XREF_LINE 26 /* xref */
X+ #define LOCALDATE_LINE 27 /* x-local-date */
X
X! #define HEAD_LAST 28 /* one more than the last one above */
X
X struct headtype {
X char *ht_name; /* header line identifier */
X***************
X*** 95,101 ****
X {"sender", 0, 0, 6, 0 },
X {"summary", 0, 0, 7, 0 },
X {"subject", 0, 0, 7, HT_MAGIC },
X! {"xref", 0, 0, 4, HT_HIDE }
X };
X #endif
X
X--- 99,106 ----
X {"sender", 0, 0, 6, 0 },
X {"summary", 0, 0, 7, 0 },
X {"subject", 0, 0, 7, HT_MAGIC },
X! {"xref", 0, 0, 4, HT_HIDE },
X! {"x-local-date", 0, 0, 12, HT_HIDE }
X };
X #endif
X
X*** /tmp/,RCSt1a06028 Wed Nov 29 21:53:09 1989
X--- art.c Wed Nov 29 21:52:52 1989
X***************
X*** 87,92 ****
X--- 90,97 ----
X register char *s;
X ART_POS artsize; /* size in bytes of article */
X bool hide_this_line = FALSE; /* hidden header line? */
X+ bool local_date_shown = FALSE; /* magic local date hack */
X+ bool date_shown = FALSE; /* magic local date hack */
X ART_LINE linenum; /* line # on page, 1 origin */
X #ifdef ULSMARTS
X bool under_lining = FALSE;
X***************
X*** 229,234 ****
X--- 234,251 ----
X if (!(htype[EXPIR_LINE].ht_flags & HT_HIDE))
X hide_this_line = (strlen(art_buf) < 10);
X }
X+ else if (in_header == LOCALDATE_LINE) {
X+ hide_this_line = FALSE;
X+ local_date_shown = TRUE;
X+ if (!date_shown && do_hiding)
X+ strcpy(art_buf, &art_buf[8]);
X+ }
X+ }
X+ if (in_header == DATE_LINE) {
X+ if (local_date_shown)
X+ hide_this_line = TRUE;
X+ else
X+ date_shown = TRUE;
X }
X if (in_header == SUBJ_LINE &&
X htype[SUBJ_LINE].ht_flags & HT_MAGIC) {
SHAR_EOF
if test 2196 -ne "`wc -c < 'rn.diffs'`"
then
echo shar: error transmitting "'rn.diffs'" '(should have been 2196 characters)'
fi
fi # end of overwriting check
# End of shell archive
exit 0jef@ace.ee.lbl.gov (Jef Poskanzer) (11/30/89)
In the referenced message, Jef Poskanzer <jef@well.sf.ca.us> wrote: }The second, rn.diffs, modifies rn so that if the -Hx-local-date flag is }set, the X-Local-Date header is used in preference to the Date header. By the way, if anyone wants to post another set of diffs that makes -Hdate show the date in the reader's local time, I'll certainly be grateful. However, I suspect it will be a bit larger than the x-local-date set, since rn currently does not do any date parsing. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "It's the cows."
kjones@talos.uucp (Kyle Jones) (11/30/89)
Jef Poskanzer writes: > However, Henry's objection makes more sense. I wasn't aware that > time zone notation was not standardized. That's rather unfortunate, > and I agree that it blows this scheme out of the water. Not if the "+/- hhmm" timezone form is used instead of EST, EDT, etc. E.g. Date: Thu, 30 Nov 89 09:10:00 -0500 would be the header generated here this morning at 9:10am, Eastern Standard Time. RFC 822 supports this form.
dricejb@drilex.UUCP (Craig Jackson drilex1) (11/30/89)
In article <14749@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: >I'll be posting patches to add a checksum header sometime soon, but >meanwhile here's something else to discuss. News articles currently >put GMT in the "Date:" header. This may even be required by the news >RFC, I don't know. It is obviously not required by the mail RFC that >the news one is built on. But RFC or no RFC, it seems to me that it >would be better if the date were in the local time at the originating >machine. The reasoning is twofold: > >1) It's easy to go from local times to GMT, but it's impossible to go >from GMT to the appropriate local time since you don't know which one >is appropriate. Thus if people started posting in local time but someone >absolutely had to see GMT, he could easily modify his newsreaders to >parse the date field and convert. In other words, it doesn't break >anything (too badly). This is not true. There is no universally accepted list of local time abbreviations. The classic example is "BST"--it can either mean "British Summer Time" or "Bering Standard Time" (in the regions around the Bering Strait). The only way they could be easily convertable is if there were a minutes-from-GMT field included as well. In addition, "GMT" is all you can count on when the OS is Unix--by definition. If the kernel hasn't been reconfigured and the system isn't running ADO's time-conversion package, then the local time is likely to be off. If it's an older Unix system, the local time is likely to be off where the local legislature has changed the rules. I quote "GMT" above because Unix time is only *defined* as GMT. That doesn't mean that the clocks are set right. >2) Displaying the time in GMT is of limited utility - the only reason >for it that I can think of is to enable a human to tell the posting >order of a set of messages, but who does that kind of thing manually? You have a point here--I've often looked at the Date header, then looked at the organization line for a location, and tried to interpolate a timezone to figure out what the local time of the poster was. >On the other hand, displaying local time would be very useful. In >local-distribution newsgroups, there is no reason to use anything >else. In world-wide newsgroups, local time might tell you that a >message was posted at 4 in the morning, explaining its lack of >coherence. How do you know that the poster isn't really on the night shift, about ready for dinner? >Am I missing anything, or should I go ahead and post the patches? I don't think it would be a good idea--unless your patches merely added a local-time offset to the headers. > Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
brad@looking.on.ca (Brad Templeton) (12/01/89)
Actually, since the local time/date is more of a comment then anything else, it makes sense to make it small and simple. Ie. "Wed, 3pm PST" is good enough for me. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
jef@well.UUCP (Jef Poskanzer) (12/01/89)
In the referenced message, kjones@talos.uu.net wrote: }Jef Poskanzer writes: } > However, Henry's objection makes more sense. I wasn't aware that } > time zone notation was not standardized. That's rather unfortunate, } > and I agree that it blows this scheme out of the water. } }Not if the "+/- hhmm" timezone form is used instead of EST, EDT, etc. E.g. } Date: Thu, 30 Nov 89 09:10:00 -0500 The more I think about this idea, the more I like it. Now I'm really tempted to punt the X-Local-Date hack and do this instead. Let's see if anyone comes up with any objections. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "I either want less corruption, or more chance to participate in it." -- Ashleigh Brilliant
henry@utzoo.uucp (Henry Spencer) (12/01/89)
In article <14783@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: >}Not if the "+/- hhmm" timezone form is used instead of EST, EDT, etc. E.g. >} Date: Thu, 30 Nov 89 09:10:00 -0500 > >The more I think about this idea, the more I like it. Now I'm really >tempted to punt the X-Local-Date hack and do this instead... Be very careful that you do it right. You *can't* just append the "+/-hhmm" to any random date format; getdate barfs on some such combinations. The one above does work. RFC1036 (and most news software!) requires that dates be acceptable to getdate. (The getdate *command* shipped with C News is an easy way to test this.) For the moment, the official C News will continue to generate GMT dates. I frankly don't see the usefulness of including the timezone information. If you see an article from me posted at 0900 EST, that does not mean it's likely to be coherent and correct; quite the reverse, since I'm normally asleep at 0900. If you see one from me posted at 0100 EST, it doesn't mean I posted it when I was dog-tired after a late night -- that's not late for me. And let us not forget that thanks to various idiot manufacturers, not all binary-only systems can set their timezones correct. I routinely get mail from a friend of mine in Australia with the postmark claiming that her machine is on EST, which it most assuredly is not. She hasn't been able to find a fix. -- Mars can wait: we've barely | Henry Spencer at U of Toronto Zoology started exploring the Moon. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jef@well.UUCP (Jef Poskanzer) (12/01/89)
In the referenced message, brad@looking.on.ca (Brad Templeton) wrote:
}Actually, since the local time/date is more of a comment then anything else,
You're wrong.
Or is this one of your little "jokes" where you pretend to be stupid and
then send purile email to anyone who takes your message at face value?
---
Jef
Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef
When in doubt, sprinkle with cheese and bake.brian@ucsd.Edu (Brian Kantor) (12/01/89)
Several people have pointed out that my proposal was flawed; the right thing to do is 14 Nov 89 16:30:44 -0800 where the date is the LOCAL time. If the offset is missing, it's GMT. On systems where this breaks getdate, you'll have to elide anything past the time. That's a problem. The other problem is that this is probably not backwards compatable. I suspect it'll have to be an X-Local-Date: until we have a flag day, which I don't see happening. There's too much news software out there that wouldn't cope if we just did it. - Brian
rhg@cpsolv.UUCP (Richard H. Gumpertz) (12/02/89)
In article <10226@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes: > >You could just include it after the date on the same line, if you wish. >e.g., > Date: 29 Nov 89 12:53:48 GMT -0800 The above doesn't meet any standards for time transmission. Why invent yet another syntax? What is wrong with the following? Date: 29 Nov 89 04:53:48 -0800 Computers are good at adding back the 8 hours if you really want GMT. -- =============================================================================== | Richard H. Gumpertz rhg%cpsolv@uunet.uu.NET -or- ...uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ===============================================================================
billd@fps.com (Bill Davids_on) (12/02/89)
In article <14785@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: >In the referenced message, brad@looking.on.ca (Brad Templeton) wrote: >}Actually, since the local time/date is more of a comment then anything else, > >You're wrong. [with no explantion of why] Uses of the "Date" header: 1. So the person reading the article can know when the article was posted (this qualifies for comment status) 2. expire -p (rarely used) 3. Some news readers sort articles with the same subject by posting date (example: nn). This helps you get follow-ups in the correct order (I hate reading follow-ups to articles I haven't seen yet). If we were to put this to a vote, I'd go for the form of: Date: 30 Nov 89 19:20:21 -0700 It has the advantage of still being GMT and also giving the proper conversion (you don't have to know the rules for every country in the world or even state in the US). Someone said it's valid for RFC 822. Does getdate() handle this form? If not, we should fix it. --Bill Davidson
allbery@NCoast.ORG (Brandon S. Allbery) (12/02/89)
As quoted from <14783@well.UUCP> by jef@well.UUCP (Jef Poskanzer): +--------------- | The more I think about this idea, the more I like it. Now I'm really | tempted to punt the X-Local-Date hack and do this instead. Let's see if | anyone comes up with any objections. +--------------- If I remember correctly, RFC822 lists that (timezone as [+-]nnnn) as the *preferred* format. I'd say go for it. (I've got MH set up to work that way locally.) ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* expnet.all: Experiments in *net management and organization. Mail me for info.
emv@math.lsa.umich.edu (Edward Vielmetti) (12/02/89)
In article <4673@celit.fps.com> billd@fps.com (Bill Davids_on) writes:
If we were to put this to a vote, I'd go for the form of:
Date: 30 Nov 89 19:20:21 -0700
It has the advantage of still being GMT and also giving the proper
conversion (you don't have to know the rules for every country in
the world or even state in the US). Someone said it's valid for RFC
822. Does getdate() handle this form? If not, we should fix it.
--Bill Davidson
Bill, I don't understand your comment of it "still being GMT". Do
you mean that your Date: is really
Date: 30 Nov 89 12:20:21 GMT
Date: 30 Nov 89 19:20:21 GMT
or Date: 1 Dec 89 02:20:21 GMT ?
I would add that it's too late to "fix" getdate() -- what it is is what
you've got, you have to live within its restrictions.
If the date format is going to change, then this function in gnus needs to
know about it. It is not as general a date parser as getdate(), not by
a long shot.
(defun gnus-comparable-date (date)
"Make comparable string by string-lessp from DATE."
;; Can understand the following styles:
;; (1) 14 Apr 89 03:20:12 GMT
;; (2) Fri, 17 Mar 89 4:01:33 GMT
--Ed
[follow-ups to gnu.emacs.gnus, I guess.]brad@looking.on.ca (Brad Templeton) (12/02/89)
In article <14785@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: >You're wrong. > >Or is this one of your little "jokes" where you pretend to be stupid and >then send purile email to anyone who takes your message at face value? >--- >Jef What is with you, that you feel you have to respond to postings with strange statements, insults and references to the poster's person rather than the matters at hand. That may be the way they do things in news.groups [:-(] but I hope I speak for most people here when I say this style of discussion is not welcome in this group. I would have sent this by mail, but I tried that last time and it did no good. Go away. Now, to get back to the actual issue (gasp), I belive that the local time is very much like a comment, because the purpose of it is to give you an idea of the poster's subjective environment when posting the item. As it is subjective, and meant for human interpretation, it is by and large a comment. If you would like to present a case as to why my computer would care what time it was at your house when you posted your article, let's hear it. On the other hand, I can agree with the sentiment that if the information can be formally specified, it should be. But not at a cost of adding a long string to every article, that's all. The suggestion to simply use a date line with local time and a "different from Greenwich" indicator is probably the simplest. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
jthomp@texsun.Central.Sun.COM (Jim Thompson ) (12/02/89)
In article <55511@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >In article <14785@well.UUCP> Jef Poskanzer <jef@well.sf.ca.us> writes: >>You're wrong. >What is with you, that you feel you have to respond to postings with >strange statements, insults and references to the poster's person rather >than the matters at hand. Well, you are wrong, and you have posted articles like the one mentioned before. He was offensive, but then, you are wrong. >I would have sent this by mail, but I tried that last time and it did >no good. Go away. Now you're being offensive. >Now, to get back to the actual issue (gasp), I belive that the local time >is very much like a comment, because the purpose of it is to give you an >idea of the poster's subjective environment when posting the item. As it >is subjective, and meant for human interpretation, it is by and large >a comment. If you would like to present a case as to why my computer would >care what time it was at your house when you posted your article, let's >hear it. Your beliefs have not much to do with what the defined standard is. Break the RFCs, and lots of us will start *actively* hunting down your style of article and dropping it on the floor. (If NNTP doesn't just do this for us.) Or have you forgotten that 99% of USENET flows via NNTP on the Internet? >On the other hand, I can agree with the sentiment that if the information >can be formally specified, it should be. But not at a cost of adding a long >string to every article, that's all. The suggestion to simply use a date >line with local time and a "different from Greenwich" indicator is probably >the simplest. I don't see what knowing the 'localtime' at site 'foo' has got to do with *anything*. If its a comment (and I belive its not!), then its a useless comment, much akin to having a header: Food: The poster was digesting pancakes and scrambled eggs. While it may be usefull for determining the state of the poster, its got nothing to do with aritcle content. I agree with you that adding a header *just* for the localtime is bad. I don't agree that anything has to happen to 'Date:'. For instance, its 8am here, but I've been up since 8am yesterday. Am I coherent? Hardly ever, at any hour. I think its quite useful the way it is. Since they're all based on a common format, its quite easy to generate an 'in-order' list of articles (not much less with the +/- HHMM format, true, but that breaks the code.) Jim Jim Thompson - Network Engineering - Sun Microsystems - jthomp@central.sun.com Member of the Fatalistic International Society for Hedonistic Youth (FISHY) "I woudn't recommend sex, drugs, or unix for everyone, but they work for me." - Me (paraphrasing Hunter S. Thompson)
pjg@urth.acsu.buffalo.edu (Paul Graham) (12/03/89)
In article <14785@well.UUCP>, jef@well (Jef Poskanzer) writes: >In the referenced message, brad@looking.on.ca (Brad Templeton) wrote: >}Actually, since the local time/date is more of a comment then anything else, > >You're wrong. and then some other less pleasant stuff. now jef seems fairly reasonable, and while brad has his moments he's (imho) also fairly reasonable. i've followed this thread and i have every reason to believe i know what's going on and i think jef has made an unsupportable attack. of course maybe the posting was forged. it seems to be an non sequitur. if someone has some deep insight into this perhaps they can explain it to me *via mail*. --
jef@max.ee.lbl.gov (Jef Poskanzer) (12/03/89)
In the referenced message, jthomp@texsun.Central.Sun.COM (Jim Thompson ) wrote: }on a common format, its quite easy to generate an 'in-order' list }of articles (not much less with the +/- HHMM format, true, but }that breaks the code.) Breaks what code? getdate() handles it just fine. To what are you referring? Tell ya what, I'll forge this article so that its Date: is in the proposed format. Anyone who has software that actually breaks on this article, please speak up. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef All models over 18 years of age.
jef@max.ee.lbl.gov (Jef Poskanzer) (12/04/89)
In the referenced message, jthomp@texsun.Central.Sun.COM (Jim Thompson ) wrote: }on a common format, its quite easy to generate an 'in-order' list }of articles (not much less with the +/- HHMM format, true, but }that breaks the code.) [second try] Breaks what code? getdate() handles it just fine. To what are you referring? Tell ya what, I'll forge this article so that its Date: is in the proposed format. Anyone who has software that actually breaks on this article, please speak up. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef All models over 18 years of age.
jef@well.UUCP (Jef Poskanzer) (12/04/89)
Interesting. When the (second) test article left helios, it said:
Date: 3 Dec 89 08:58:48 -0800
But I'm getting reports that when it arrived on other sites it said:
Date: 3 Dec 89 16:58:48 GMT
I guess that about does it for the -0800 proposal. I'll stick with
X-Local-Date:.
---
Jef
Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef
"Offense is a human emotion." -- Sarekgnb@bby.oz (Gregory N. Bond) (12/04/89)
In article <1989Dec1.042319.26810@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
And let us not forget that thanks to various idiot manufacturers, not
all binary-only systems can set their timezones correct. I routinely
get mail from a friend of mine in Australia with the postmark claiming
that her machine is on EST, which it most assuredly is not. She hasn't
been able to find a fix.
Well, I'm not sure a fix is needed - our timezone IS EST - just not
the EST you North Americans are used to!
This is a different problem again to the SunOs 3.5Export, which had 2
versions of the Australian DST code - one in libc.a and one used to
compile all the binaries. And they differed by a week in when DST
started!!!
(Australian EST is GMT-10:00, but we're on Summer Time (EDST) now and
GMT-11:00.)
Greg. From downunder.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnbkjones@talos.uucp (Kyle Jones) (12/05/89)
Jef Poskanzer writes: > Interesting. When the (second) test article left helios, it said: > > Date: 3 Dec 89 08:58:48 -0800 > > But I'm getting reports that when it arrived on other sites it said: > > Date: 3 Dec 89 16:58:48 GMT > > I guess that about does it for the -0800 proposal. I'll stick with > X-Local-Date:. Yep, that's what I saw here. Which news software rewrites Date headers as articles pass through?
mark@sickkids.UUCP (Mark Bartelt) (12/13/89)
We've seen nearly three dozen articles on this ridiculous topic, and
I don't believe anyone, including Mr. Poskanzer himself, has provided
any explanation as to why anyone *cares* what the local time was when
an article was posted.
Jim Thompson was quite correct when he pointed out that such a feature
would make about as much sense as
Food: The poster was digesting pancakes and scrambled eggs
Before anyone goes off half-cocked and patches their news software to
add a new "X-Local-Date:" header, or muck with the "Date:" line, or
perform some other sort of atrocity, it might be wise to pause for a
moment and recall the term coined by Rob Pike: creeping featurism.
Meaning, of course, that all too many people are better at adding
new features to programs than they are at making sensible judgments
about whether those features ought to be there in the first place.
One could certainly argue that the netnews software passed the threshold
of reasonableness ages ago, but that's no justification for encrusting it
with still more cruft of dubious value.
Mark Bartelt INTERNET: mark@sickkids.toronto.edu
Hospital for Sick Children, Toronto mark@sickkids.utoronto.ca
416/598-6442 UUCP: {utzoo,decvax}!sickkids!markjef@ace.ee.lbl.gov (Jef Poskanzer) (12/14/89)
In the referenced message, mark@sickkids.UUCP (Mark Bartelt) wrote: }We've seen nearly three dozen articles on this ridiculous topic, and }I don't believe anyone, including Mr. Poskanzer himself, has provided }any explanation as to why anyone *cares* what the local time was when }an article was posted. I posted an explanation in the original article. Admittedly, I was joking, but I thought the real reason would be obvious: I want to see the local time on locally-posted articles. Adding X-Local-Date: turns out to be the simplest way to get this. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef "If a pickpocket meets a saint, he will see only the saint's pockets." -- Hari Dass Baba
rick@uunet.UU.NET (Rick Adams) (12/15/89)
> I posted an explanation in the original article. Admittedly, I was > joking, but I thought the real reason would be obvious: I want to see > the local time on locally-posted articles. Adding X-Local-Date: turns > out to be the simplest way to get this. Given that correctly working news software converts posters local time to GMT on posting and converts GMT to readers local time on reading, whats the problem? The transformation should be identical. (or are you using a broken news reader) --rick
jef@well.UUCP (Jef Poskanzer) (12/15/89)
In the referenced message, rick@uunet.UU.NET (Rick Adams) wrote: }Given that correctly working news software converts posters local }time to GMT on posting and converts GMT to readers local time }on reading, whats the problem? The transformation should be identical. }(or are you using a broken news reader) Rick has informed me by mail that when he says "correctly working news software" he does not mean rn. As the majority of the net knows, rn does not transform GMT into reader's local time. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef END CONSTRUCTION