Subject: draft-06, datetime regexp

From: Danny Ayers <[email-masked]>
Date: Thu, 17 Mar 2005 23:52:03 +0100

I only noticed the new draft on my way to bed, have only skimmed but
this looks a bit clunky:

-----------------------
3.3  Date Constructs

   A Date construct is an element whose content MUST conform to the
   date-time BNF rule in [RFC3339].  I.e., the content of this element
   matches this regular expression

   [0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)
        ?(Z|[\+\-][0-9]{2}:[0-9]{2})

   As a result, the date values conform to the following specifications:
   [RFC3339], [W3C.REC-xmlschema-2-20041028],
   [W3C.NOTE-datetime-19980827], and [ISO.8601.1988].
-----------------------

Personally I don't think the regexp really helps, it's not normative
(which regexp spec?) and not very informative (aren't they NFL
scores?). An example or two would be more use in recognising and
understanding the format(s) being referred to.

he examples in RFC 3339 work well, e.g.

[[
      1996-12-19T16:39:57-08:00

   This represents 39 minutes and 57 seconds after the 16th hour of
   December 19th, 1996 with an offset of -08:00 from UTC (Pacific
   Standard Time).  Note that this is equivalent to 1996-12-20T00:39:57Z
   in UTC.
]]

Wouldn't something like that be clearer?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Thu, 17 Mar 2005 15:13:24 -0800

> 3.3  Date Constructs
...
> understanding the format(s) being referred to.

Sorry, this was discussed a lot and the regex has massive support.  
Having said that...

> he examples in RFC 3339 work well, e.g.

More examples in the draft would be good. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 17 Mar 2005 18:19:22 -0500

> More examples in the draft would be good. -Tim

Agree, but is Danny right about the missing normative reference? And 
shoot, we also missed the reference for the ABNF in atom:link.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Fri, 18 Mar 2005 00:37:39 +0000

On 17 Mar 2005, at 11:13 pm, Tim Bray wrote:

> OSorry, this was discussed a lot and the regex has massive support.  
> Having said that...

Pardon? I remember the concept of three-way compatibility being 
popular. The only archived discussion I can find of the regex is Norm 
and Robert proposing it, Sam supporting, Julian saying he doesn't hate 
it and me criticising it for exactly the same reasons as Danny.

Also, the regex begins:

[0-9]{8}T

Which unless I'm mistaken requires the date section to be exactly 8 
digits with no punctuation. Yet RFC3339 defines the date section as 
having hyphens:

full-date = date-fullyear "-" date-month "-" date-mday

I don't think there's better proof of the regex's awfulness than, given 
the number of eyeballs that have been on it to get it into the spec, no 
one's noticed there's a glaring error in the very first term.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 17 Mar 2005 19:56:48 -0500

> one's noticed there's a glaring error in the very first term.

Have to admit, I liked it a lot more before Graham pointed out that I 
didn't read it.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 18 Mar 2005 11:45:23 +1100

On 18/3/05 10:13 AM, "Tim Bray" <[email-masked]> wrote:

> Having said that..

the regex is mostly useful for validating a datetime element, but it's not
much good for working out how to build it.

and it's not entirely useful for validating either ... according to the
regex:

this is valid:

      19961332T25:79:57-08:91

which it isn't.

e.

---

From: Norman Walsh <[email-masked]>
Date: Mon, 21 Mar 2005 15:34:29 -0500

/ Graham <[email-masked]> was heard to say:
| Also, the regex begins:
|
| [0-9]{8}T
|
| Which unless I'm mistaken requires the date section to be exactly 8
| digits with no punctuation. Yet RFC3339 defines the date section as
| having hyphens:

Agreed. That should be [0-9]{4}-[0-9]{2}-[0-9]{2}

| full-date = date-fullyear "-" date-month "-" date-mday
|
| I don't think there's better proof of the regex's awfulness than,
| given the number of eyeballs that have been on it to get it into the
| spec, no one's noticed there's a glaring error in the very first term.

Uhm. Yeah. Fair point.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.