[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: date formats
On Thu, Dec 07, 2000 at 10:40:58AM -0500, Greg Ferguson wrote:
> On Dec 7, 9:06am, David Merrill wrote:
> > Subject: date formats
> > The LAG, section 6.1, says that:
> >
> > The <pubdate> tag in your header should be in the following format:
> >
> > v1.0, 21 April 2000
> >
> > This seems strange to me. The version number has nothing to do with
> > the date of publication. The example in DocBook:TDG uses only the year
> > of publication here, but doesn't give specific enough information to
> > know whether this is the recommended usage. Anybody know?
> >
> > I take it, literally, to mean that this applies only to the <pubdate>
> > tag. What about other date tags, particularly the date in revhistory?
> >
> > <revhistory>
> > <revision>
> > <revnumber>1.0</revnumber>
> > <date>27 de janeiro de 2000</date> <- taken from example.sgml
> >
> > This particular example also brings up another wrinkle - language.
> > If we are using month names, then they could be in many different
> > languages. Using a standard ISO date format would mean fewer
> > differences in the dates:
> >
> > <date>2000-01-27</date>
> >
> > not to mention being easier to parse in scripts.
>
> As long as we are assured it's YYYY-MM-DD and not YYYY-DD-MM.
> I'd advocate using "DD MMM YYYY", where MMM = {Jan, Feb, etc};
> no descrepency or confusion.
{Jan, Feb, etc} regardless of the language doesn't make sense. I like
YYYY-MM-DD because 1) it is language-independent, 2) it follows the
ISO standard 3) it is easily parsed 4) it is unambiguous.
In support of 4):
AFAIK, nobody uses YYYY-MM-DD. The ambiguous dates are those where the
year falls last (US usage is MM-DD-YYYY while English (and others) is
DD-MM-YYYY).
> > Is there already a "standard" in place for this that I'm unaware of?
> > If so, let me know and I'll add it into the same section of the LAG as
> > the <pubdate> reference. If not, let's set one, please.
>
> The format is (I believe) a hold-over from the linuxdoc DTD. As I read
> it, linuxdoc does not have a tag for any sort of version specification
> (if one has been added, to a recent snapshot of the linuxdoc-tools,
> please lmk). Therefore, all data is supplied in the <date> tag, as:
>
> <date>v1.0, 21 April 2000</date>
>
> We carried that over to DocBook, using the <pubdate> tag.
> You're right, it's not the best/proper use of the tag; esp.
> given the wealth of tags to use in DocBook.
>
> In fact, I'm not so sure <pubdate> needs to be used at all.
> Does this represent the current date of the publication, or
> the date the document was *initially* published? How does this
> coincide with the <date> within a <revision> grouping? I suppose
> revisions can occur without publishing, but it would seem like
> the very first <revision> entry in the <revhistory> (the latest
> revision) would be the accurate date field to use.
Looking at the examples in DocBook:TDG, I see:
1994
Winter, 1996
1997
They seem also to use the date of current publication, or date of
publication of this edition. One example shows a document with
<pubdate>1997</pubdate>
<copyright><year>1992</year>
<year>1993</year>
<year>1994</year>
<year>1995</year>
<year>1996</year>
<year>1997</year>
etc., which means in the example they're using the date of publication
of the current edition/version.
> In the SGML parsing routines I've built, this is the nastiest part
> (as you've seen!). I parse for and use <revision>, <date>,
> <pubdate>, etc. - I try to use whatever the author has supplied
> (DTD specific).
>
> A recommendation is outlined below; I've extended this as to what
> I think would comprise a good/valid MINIMUM set of elements for
> a header area for LDP documents:
I like the recommendation except for my stated opinion on the date
format. However, I think it would be a good idea to print our example
using *all* (or at least *most*!) possible tags rather than the
minimal set. It is easier for a novice to remove the tags they don't
want than it is to add the ones they do. It also encourages them to
use the tags. More meta-data is, in general, a Good Thing.
> <revision>
> <revnumber>v2.0</revnumber>
> <date>DD MMM YYYY</date>
> </revision>
I don't like the "v" inside the revision number. It is not really part
of the revision number, but a label placed in front of it to indicate
what it is. Do you include it because it needs to appear in the
output? That's certainly more important than my niggling about whether
or not it is really part of the revision number. :-)
--
Dr. David C. Merrill http://www.lupercalia.net
Linux Documentation Project dmerrill@lupercalia.net
Collection Editor & Coordinator http://www.linuxdoc.org
I'm not even going to *______bother* comparing C to BASIC or FORTRAN.
-- L. Zolman, creator of BDS C
--
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org