Jim Meyering [EMAIL PROTECTED] writes:
BTW, I don't like the fact that the new %:z formats zero-fill by default,
when used with a wider field width, but I've left it as-is, for now.
Hmm, RFC 3339 requires the leading zero in +07:00. Some people like
+7 and they can have that by specifying a
Eric Blake [EMAIL PROTECTED] writes:
All I could think of when the problem first came up was %Ez, since %E
specifies alternate format, but that doesn't really fit the three formats
you provided, so your choice seems great to me.
Thanks. Also, %E is supposed to be about locales, but this
Paul Eggert [EMAIL PROTECTED] wrote:
2005-09-13 Paul Eggert [EMAIL PROTECTED]
* NEWS: date has a new --rfc-3339 option, and the old --iso-8601
option is deprecated. date and ls also have new time format
specifiers %:z, %::z, %:::z.
So my threat of incoming fprintftime
Jim Meyering [EMAIL PROTECTED] wrote:
...
2005-09-14 Jim Meyering [EMAIL PROTECTED]
* strftime.c (my_strftime): Parse the colons of %:::z *after* the
optional field width, not before, so we accept %9:z, not %:9z.
2005-09-14 Jim Meyering [EMAIL PROTECTED]
*
Jim Meyering [EMAIL PROTECTED] writes:
Paul Eggert [EMAIL PROTECTED] wrote:
How about if we do it by supporting Internet RFC 3339 instead?
I like this.
OK, I installed the patch below. Comments welcome. In particular,
the new %:z, %::z, %:::z strftime formats are a bit weird-looking, but
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 9/13/2005 4:16 PM:
OK, I installed the patch below. Comments welcome. In particular,
the new %:z, %::z, %:::z strftime formats are a bit weird-looking, but
I couldn't think of anything better.
All I could think of
Paul Eggert [EMAIL PROTECTED] wrote:
...
How about if we do it by supporting Internet RFC 3339 instead?
...
I like this.
...
3. For convenience, introduce a new short option -i that is
equivalent to --rfc-3339 with the default TIMESPEC. The mnemonic
is that -i is short for Internet
Hi Paul,
On Fri, Jul 22, 2005 at 09:30:42AM -0700, Paul Eggert wrote:
Jos Backus [EMAIL PROTECTED] writes:
It would seem that GNU date should simply dispense with emitting the `T'
between the date and time field in IOS 8601 mode until the parsing of this
particular format is
I added some comments to bug 11290
(https://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=11290) which
pertains to this issue.
It would seem that GNU date should simply dispense with emitting the `T'
between the date and time field in IOS 8601 mode until the parsing of this
particular
Nic Ferrier [EMAIL PROTECTED] writes:
Curiously it seems to be the timezone that it doing it because this
DOES work:
$ date --date 2004-12-18T17:28:00
GNU date parsed the T as the military time zone T.
Adding support for more ISO date forms is on the list of things to do.
It is
Paul Eggert [EMAIL PROTECTED] writes:
Nic Ferrier [EMAIL PROTECTED] writes:
Curiously it seems to be the timezone that it doing it because this
DOES work:
$ date --date 2004-12-18T17:28:00
GNU date parsed the T as the military time zone T.
Adding support for more ISO date forms is on
Nic Ferrier [EMAIL PROTECTED] writes:
Note the third item:
$ date --iso-8601=seconds # a GNU extension
2000-12-15T11:48:05-0800
Ah, I missed that the first time. Thanks. I installed this patch,
in both coreutils and gnulib:
2005-05-11 Paul Eggert [EMAIL PROTECTED]
*
As I read the documentation for gnu date it should parse iso-8601
dates correctly:
File: coreutils.info, Node: General date syntax
.
.
.
The output of `date' is not always acceptable as a date string, not
only because of the language problem, but also because there is
13 matches
Mail list logo
