parse-date problems

[cormullion]

I'm having trouble understanding parse-date's limitations.

Code Select Expand

>(parse-date "20080403" "%Y%m%d")
nil
> (parse-date "2008 01 03" "%Y %m %d")
1199318400
> (parse-date "20080411234423" "%Y%m%d%H%M%S")
nil
> (parse-date "2008 04 11 23 44 23" "%Y %m %d %H %M %S")
1207957463
>


For some reason I was convinced that they should work without spaces...

[Lutz]

I agree it would be nice if it works without characters in-between format specifiers. Unfortunately this is how the underlying C library function has been implemented.

[cormullion]

Further research shows it works on newLISP 9.2 on BSD:

Code Select Expand

newLISP v.9.2.0 on BSD, execute 'newlisp -h' for more info.

> (parse-date "20080403" "%Y%m%d")                                  
1207180800


Perhaps it's a platform-related issue. I'll install 9.2 here on Mac and see what the result is...

[cormullion]

It's OK on 9.2 (well, 9.1.9) on MacOS X:

Code Select Expand

newLISP v.9.1.9 on OSX UTF-8, execute 'newlisp -h' for more info.

> (parse-date "20080403" "%Y%m%d")
1207180800
>


[Lutz]

... but when compiling 9.1.9 again on Mac OS X (this time Leopard) it also doesn't work anymore. It seems that libc.dylib on Mac OS X has been broken for that function ( strptime() )between OS X 10.4 and 10.5.

[Lutz]

... also working fine on Solaris.

[cormullion]

So basically it's only an issue for 9.3 on MacOS (and 9.2 if you recompile on Leopard)...



Now that I know it's an easy enough problem to avoid...  In my previous blogging app I used the ISO8601-style identifiers which I parsed with (parse-date). For the next one I'll just split up the 14-character string into chunks, since it has a predictable structure...