[buug] date/time formats, standards, options, bloat, ... (was: ISO date format)

Fri Jan 18 11:57:03 PST 2013

Ah, good points.  I'd forgotten about %F, but alas, it's not (yet?) in
POSIX/SUS[1].  Likewise for %z and %:z.

And -I, okay, stating/implying it as "conveniently available" in GNU
date[2] was probably bit of an overstatement on my part, as it is
deprecated and it may become inconveniently unavailable in any future
version.  I did however show it in example as interactive usage, not in
some script or program.  Though some of GNU's documentation states it
as deprecated, would be better if that was much more consistent.  E.g.
in [2], in that context, it makes no mention there of being deprecated.

And yes, standards do evolve.  ISO 8601[3] is good, but also older.
RFC 3339[4] didn't yet exist in 1998.  It can well be argued that RFC
3999 has advantages over ISO 8601.  And, perhaps to lesser extent, it
could also be argued that ISO 8601 has some advantages over RFC 3339
(e.g. RFC 3339 doesn't even attempt to address ranges of time).
Fortunately, ISO 8601 and RFC 3339 do also have quite a bit in common.
What's been more widely adopted (e.g. ISO 8601 or RFC 3339) probably
depends not only on context (e.g. Internet protocols vs. more general
usage by/for humans, standard bodies, and countries), but may also
change and shift over time.  But it's quite clear, for Internet
protocols currently RFC 3339 would generally be most appropriate and
applicable, whereas in other contexts, it might be ISO 8601, rather
than RFC 3339.  It's also worth noting that ISO 8601 and RFC 3339 do
address rather different objectives.

ISO 8601 more generally covers date/time formats and related data and
interchange, and has a fairly wide variety of formats to accommodate
somewhat different needs (e.g. time ranges, week-of-year formats
commonly used in e.g. manufacturing industries, lower precision formats
e.g. specifying only year and month, or only year, etc.)

RFC 3339 aims to simplify by only addressing specific time instants,
unambiguously and to precision of second and only rarely more
precisely, reducing variations in possible formatting and probabilities
of errors and bugs - including implementation of specification and
interpretation of conforming data, while also having reasonable
allowance for human readability, and with a primary focus on use as
standard format in Internet protocols.

(options, bloat, ramble, ramble ...)
For the most part, I like to stick with and favor good standards, and
shy away from non-standard (e.g. GNU) extensions.  But there are some I
do very much like and I find have much merit, and I'd like to see - at
least in some comparable form, make it into POSIX/SUS standards.  But,
a whole lot of GNU extensions I often find to be rather bloated
overkill, and not so useful.  Examples of GNU extension I quite like:
the -0 and similar options to GNU's find (-print0), cpio, xargs, etc.
It's so useful perl also has quite similar, as does BSD in, e.g. pax.
I'd like to see POSIX/SUS date(1) with minimally extended yet sufficient
additional formatting options to reasonably generate most common ISO
8601 and RFC 3339 formats - and with not nearly so large and complex
(and not particularly stable) set of options as GNU date has.

Sure, might be handy to have capability to convert from a relatively
arbitrary timestamp to another date format or calculate a timestamp
relative to another given timestamp and offset, but *really*, do we
need to glob all that onto the date(1) command - particularly for
command that also likely gets used by superuser?  Sounds hazardously
bloated.  Seems to me a whole lot of that functionality ought to be
stripped out of the date command, and would probably best be placed in
a completely separate utility command.  I think many of the points
about simplicity and rarely used options ought quite be applied to
(re)design of the GNU date command - but hey, that's just my opinion.
GNU date is brought to you by (some of) the same fine folks also
responsible for emacs - and, well, they may have very different design
criteria compared to what I'd have in mind.

footnotes/references/excerpts:
1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html
2.  
http://www.gnu.org/software/coreutils/manual/html_node/Options-for-date.html#Options-for-date
3. http://en.wikipedia.org/wiki/ISO_8601
4. http://www.ietf.org/rfc/rfc3339.txt

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [buug] ISO date format
> Date: Thu, 17 Jan 2013 20:31:10 -0800

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> or additionally, on systems with GNU date[3]:
>> $ date -I
>> 2013-01-17
>
> I'm feeling like I've just gone through a time warp to March 2007, when
> this whole subject was discussed to death on Don Marti's linux-elitists
> mailing list -- including the reason why the above is a bad idea.
> Quoting part of that thread:
>
>    From rick Sat Mar  3 21:56:53 2007
>    Date: Sat, 3 Mar 2007 21:56:54 -0800
>    To: linux-elitists at zgp.org
>    Subject: Re: [linux-elitists] Show Us The Code
>
>    Quoting David L. Anselmi (anselmi at anselmi.us):
>
>    > The Debian bug on this says that --iso-8601 is deprecated in favor of
>    > --rfc-3339 and contains links to the upstream discussion:
>    >
>    > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354799
>    >
>    > Be nice if there were a short option, I guess.
>
>    '-I' is now deprecated (and deliberately dropped from the manpage, which
>    seems bloody minded) for the same reason that --iso-8601 was.  Option
>    -i was proposed as a replacement short option (standing for 'Internet
>    time'), but rejected because Paul Eggert's PC clock was too jittery
>    (http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00056.html).
>
>    So, the best approximation we'll be permitted to the brevity and clarity
>    of 'date -I' is
>
>      date +%Y-%m-%d
>    or
>      date --rfc-3339=date
>
>    Argh.  Just kill me now.
>
> So, sorry, no, you really should _not_ recommend 'date -I' to people using
> GNU date, because the GNU coreutils people have already telegraphed their
> intention to drop that option from future versions.
>
> After the aforementioned linux-elitists thread, I figured out a
> reasonable alternative (for GNU date users) that is _not_ similarly
> destined to be dropped into the dustbin:
>
> date +%F
>
>
>
>> At the last (2012-01-03) BUUG meeting, among other things discussed,
>> date and date/time format came up.  I mentioned ISO[1] date format....
>
> I believe you mean ISO 8601 format.
>
>
>> And yes, I've at least occasionally made earlier mention[4] of ISO date
>> format.
>> 4.  
>> http://lists.balug.org/pipermail/balug-talk-balug.org/2010-February/004557.html
>
> And I told you about 'date +%F' at that time, too, in my immediate follow-up:
> http://lists.balug.org/pipermail/balug-talk-balug.org/2010-February/004559.html
>
> --
> Cheers,             A programmer had a problem. He thought to  
> himself, "I know,
> Rick Moen           I'll solve it with threads!".  has Now problems. two he
> rick at linuxmafia.com                                        -- Davidlohr Bueso
> McQ! (4x80)