Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!mailrus!iuvax!watmath!looking!brad
From: brad@looking.on.ca (Brad Templeton)
Newsgroups: news.software.b
Subject: Re: Our friend, the GMT date.
Message-ID: <56239@looking.on.ca>
Date: 4 Dec 89 06:57:49 GMT
References: <4364@helios.ee.lbl.gov> <14810@well.UUCP> <1989Dec3.210413.27043@psuvax1.cs.psu.edu>
Organization: Looking Glass Software Ltd.
Lines: 32
Class: discussion

Almost makes me wonder if we/they shouldn't have started with a machine
only date field, integer seconds since some epoch.  (Could use the Unix
epoch, or even the USENET epoch, I guess.)

This would have taken out the complex getdate routine from both news
database programs and readers that try to understand the date, as well
as eliminating these problems.

The readers would need a very simple date printing routine like ctime,
that works from a seconds-since-epoch value.  This is found just about
everywhere, and certainly any Unix.

But it's too late to change now.  The only way a change could be done
would be to support both for many years, and that's hardly a solution!
(Based on news upgrades out in the field, at least 10 years!)

(To please those keen on the local time, a date plus time zone value, in
plus/minus minutes, would have done the trick)

I think RFC 822, which we followed, is also silly to express the time
in a human format.  There are a zillion ways of writing the date out
there, and you can never satisfy everybody.  Sigh.

Of course, it could be arranged to output the old date only when feeding
old sites, and to convert incomings, but that's still to messy.

To those who say, "I want to write the date my way, how dare you rewrite it?"
I say, "why?"   Why do you want to write the date a different way.  All
that really matters is how it is displayed when it comes time to read it,
and that it be universally understood by software.
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473