ParseDateTime Patterns

[Peter J. Farrell]

Hi All,

I'm bring this up because all the engines appear to support a different
array of datetime patterns in ParseDateTime(). The normal and commonly
used ones work the same across all engines, but for example the engines
compat on Unix date string were widely different.

Unix Date Strings:

This was proposed a originally in the OpenBD tracker. I think mostly
because the Twitter API returns all date / times in this format.

<cfset dt = "Wed Dec 23 05:34:28 +0000 2009">
<cfdump var=#parsedatetime( dt )#>

OpenBD: works as of Feb 1, 2011 BER / Nightly -
http://code.google.com/p/openbluedragon/issues/detail?id=186

ACF8: parses that date, but incorrectly assigns the year as 2000 i.e.
{ts '2000-12-23 05:34:28'}

Railo: ? - maybe somebody can report back

HTTP Timestamp:

Anybody doing work with headers like cache until need to work with HTTP
timestamps. It seems like this is another format that ParseDateTime()
should just work.

<cfset dt = "11 Aug 2010 17:58:48 GMT">
<cfdump var=#parsedatetime( dt )#>

OpenBD: proposed as
http://code.google.com/p/openbluedragon/issues/detail?id=260

ACF8: doesn't work - must use a custom UDF

Railo: ? - maybe somebody can report back

Best,
.Peter

[Peter Boughton]

Tested in Railo (BER from last week, I think)...

First dump gives this:
> Date Time (Europe/London)
> {ts '2009-12-23 05:34:28'}

Second one throws an error:
> can't cast [11 Aug 2010 17:58:48 GMT] to date value

If that's the format used by HTTP then I definitely agree it should be
handled correctly by parseDateTime, and not handling it should be
considered a bug in the function.

[Peter J. Farrell]

Peter Boughton said the following on 02/02/2011 04:29 PM:

> Tested in Railo (BER from last week, I think)...
>
> First dump gives this:
>> Date Time (Europe/London)
>> {ts '2009-12-23 05:34:28'}

Great! I guess the odd man out here is ACF which parses the date, but
with an incorrect year. I filed this as a bug in ACF:

http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=86140

> Second one throws an error:
>> can't cast [11 Aug 2010 17:58:48 GMT] to date value
> If that's the format used by HTTP then I definitely agree it should be
> handled correctly by parseDateTime, and not handling it should be
> considered a bug in the function.
>

Yep, that's the correct format according to the RCF spec for HTTP. This
bug has been filed as in RAILO:

https://issues.jboss.org/browse/RAILO-907

.pjf

[Sean Daniels]

On Feb 2, 2011, at 4:54 PM, Peter J. Farrell wrote:

> <cfset dt = "Wed Dec 23 05:34:28 +0000 2009">
> <cfdump var=#parsedatetime( dt )#>

Railo 3.2.1.000 (latest production release) in New York time zone returns:

{ts '2009-12-23 00:34:28'}

Which looks correct to me.

/Sean

[Peter J. Farrell]

Sean Daniels said the following on 02/02/2011 04:32 PM:

It's close, but it is incompatible with ACF and OpenBD. By default, the
second argument "pop-conversation" is set to standard which means there
should be no time zone conversation. If "pop-conversation" is set to
"pop", then it should convert it to UTC. Either way since the TZ is
0000, the result for "standard" and "pop" should be the same:

{ts '2009-12-23 05:34:28'}

This is a compatibility issue with Railo.

Best,
.Peter