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 specify
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]>
>
>
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 fprint
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
-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 o
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,
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 "
On Fri, Jul 22, 2005 at 10:23:48AM -0700, Paul Eggert wrote:
> > Note that I haven't read the actual standards document. But if that is the
> > case, then how can the following be valid formats according to Markus Kuhn's
> > document (which w3.org links to, btw)?
>
> Because Markus Kuhn doesn't li
>> The `T' is optional according to the standard
>>
>> It is? As far as I can tell, it's required.
>
> Note that I haven't read the actual standards document. But if that is the
> case, then how can the following be valid formats according to Markus Kuhn's
> document (which w3.org links to, btw)?
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 supported. The `T' is optional according to the standard
It is? As far as I can te
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=detailitem&item_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 fo
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 mor
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]>
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
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 no
16 matches
Mail list logo
