Fixed error in validating date-time

[mikeangstadt]

Wherein valid date-time objects with milliseconds (and without trailing literal 'Z') attached were getting bounced. Now RegEx handles previous and other cases.

[mikeangstadt]

This doesn't break any tests that it affects

[tdegrunt]

Ah date-time the bane of my existence :)
Could you add one or two tests showing exactly what you fixed?
That way we can make sure it never happens again ...

[awwright]

The ABNF in the RFC doesn't technically allow for any whitespace, but the following paragraph says applications "may" (i.e. not MAY which is formally defined) use a space instead.

I have half a mind to write an ABNF-to-Regexp converter right now. (Don't forget about leap seconds, 23:59:60 is a perfectly reasonable, if uncommon, time of day)

Is there a valid RFC3339 timestamp that is invalid with the current regex?

[mikeangstadt]

Sure, not a problem.
On Aug 4, 2014 3:59 PM, "Tom de Grunt" [email protected] wrote:

Ah date-time the bane of my existence :)
Could you add one or two tests showing exactly what you fixed?
That way we can make sure it never happens again ...

—
Reply to this email directly or view it on GitHub
#84 (comment).

[mikeangstadt]

@tdegrunt added tests, formatted for easier reading.

[mikeangstadt]

@ACubed No, I've handled the loosest (including case-insensitive t,z, & allowing for whitespace, & up to 7 digit microseconds).

The two additional test cases along with those already present tighten this up quite a great deal.

[mikeangstadt]

I've added support for null values iff it is not required.

[tdegrunt]

Best to separate the code-style changes from the actual code change ..
What do you say @ACubed ? I'm inclined to merge as it gives more flexibility and is still within the specs.

[awwright]

The proposed regex:

/^\d{4}-[0-1]{1}[0-9]{1}-[0-3]{1}[0-9]{1}[Tt]{0,1}[ ]{0,1}\d{2}:\d{2}:\d{2}((\.*\d{0,7}[Zz]{0,1}$)|(\.*\d{0,7}\+\d{0,2}:\d{0,2}$)|(\.*\d{0,7}$)|$|[Zz]{0,1}$)/

fails the following example listed in RFC3339 itself:

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

Additionally, instances of {0,1} and {1} can be shortened.

My hand-crafted regex examining the ABNF looks like:

date-time = full-date "T" partial-time ("Z" / time-numoffset)
          = full-date "T" partial-time ("Z" / ( ("+" / "-") time-hour ":" time-minute ) )
          = full-date "T" (time-hour ":" time-minute ":" time-second ["." 1*DIGIT]) ("Z" / ( ("+" / "-") time-hour ":" time-minute ) )
          = /^\d{4}-\d{2}-\d{2}[Tt]\d{2}:\d{2}:\d{2}(\.\d+)?([Zz]|[+-]\d{2}:\d{2})$/

Which looks rather similar to the current regex. The current one handles arbitrary length fractions of seconds, @mikeangstadt can you provide a specific example date that isn't supported?

[mikeangstadt]

I've added a few tests, if those pass with yours & you like it better lets
go with it.
On Aug 6, 2014 6:32 AM, "Acubed" [email protected] wrote:

The proposed regex:

/^\d{4}-[0-1]{1}[0-9]{1}-[0-3]{1}[0-9]{1}[Tt]{0,1}[ ]{0,1}\d{2}:\d{2}:\d{2}((.\d{0,7}[Zz]{0,1}$)|(.\d{0,7}+\d{0,2}:\d{0,2}$)|(.*\d{0,7}$)|$|[Zz]{0,1}$)/

fails the following example listed in RFC3339 itself:

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

Additionally, instances of {0,1} and {1} can be shortened.

My hand-crafted regex examining the ABNF looks like:

date-time = full-date "T" partial-time ("Z" / time-numoffset)
= full-date "T" partial-time ("Z" / ( ("+" / "-") time-hour ":" time-minute ) )
= full-date "T" (time-hour ":" time-minute ":" time-second ["." 1*DIGIT]) ("Z" / ( ("+" / "-") time-hour ":" time-minute ) )
= /^\d{4}-\d{2}-\d{2}[Tt]\d{2}:\d{2}:\d{2}(.\d+)?([Zz]|[+-]\d{2}:\d{2})$/

Which looks rather similar to the current regex. The current one handles
arbitrary length fractions of seconds, @mikeangstadt
https://github.com/mikeangstadt can you provide a specific example date
that isn't supported?

—
Reply to this email directly or view it on GitHub
#84 (comment).

[mikeangstadt]

I've got two tests that fail with your above handcrafted, one mine - one
someone elses. I've updated my RegEx since all it needed to support it was
a slight change and added a test "should validate a RFC3339 format".

The current version passes all tests, please let me know if you can think
of any other edge cases.

Failed tests with above suggested.

  ✓ should validate a valid date-time

  ✓ should validate a valid date-time without milliseconds

  ✓ should validate a date-time with a timezone offset instead of Z

  ✓ should validate a date-time with timezone adjustment and

milliseconds

  1) should validate a date-time with milliseconds <fail

  ✓ should validate a date-time with a z instead of a Z

  ✓ should validate a date-time with a z instead of a Z

  2) should validate a date-time with a space instead of a T <fail

  ✓ should validate a date-time with a t instead of a T

  ✓ should not validate a date-time with the time missing

  ✓ should not validate an invalid date-time

  ✓ should not validate a date-time with a timezone offset AND a Z

On Wed, Aug 6, 2014 at 7:20 AM, Michael Angstadt [email protected]
wrote:

I've added a few tests, if those pass with yours & you like it better lets
go with it.
On Aug 6, 2014 6:32 AM, "Acubed" [email protected] wrote:

The proposed regex:

/^\d{4}-[0-1]{1}[0-9]{1}-[0-3]{1}[0-9]{1}[Tt]{0,1}[ ]{0,1}\d{2}:\d{2}:\d{2}((.\d{0,7}[Zz]{0,1}$)|(.\d{0,7}+\d{0,2}:\d{0,2}$)|(.*\d{0,7}$)|$|[Zz]{0,1}$)/

fails the following example listed in RFC3339 itself:

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

Additionally, instances of {0,1} and {1} can be shortened.

My hand-crafted regex examining the ABNF looks like:

date-time = full-date "T" partial-time ("Z" / time-numoffset)
= full-date "T" partial-time ("Z" / ( ("+" / "-") time-hour ":" time-minute ) )
= full-date "T" (time-hour ":" time-minute ":" time-second ["." 1*DIGIT]) ("Z" / ( ("+" / "-") time-hour ":" time-minute ) )
= /^\d{4}-\d{2}-\d{2}[Tt]\d{2}:\d{2}:\d{2}(.\d+)?([Zz]|[+-]\d{2}:\d{2})$/

Which looks rather similar to the current regex. The current one handles
arbitrary length fractions of seconds, @mikeangstadt
https://github.com/mikeangstadt can you provide a specific example
date that isn't supported?

—
Reply to this email directly or view it on GitHub
#84 (comment).

Mike Angstadt
www.mikeangstadt.com
@mike_angstadt http://www.twitter.com/mike_angstadt | LinkedIn
http://www.linkedin.com/in/mikeangstadt
610-914-4409

"The noblest pleasure is the joy of understanding" - Leonardo Di Vinci