I'm having trouble understanding parse-date's limitations.
>(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...
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.
Further research shows it works on newLISP 9.2 on BSD:
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...
It's OK on 9.2 (well, 9.1.9) on MacOS X:
newLISP v.9.1.9 on OSX UTF-8, execute 'newlisp -h' for more info.
> (parse-date "20080403" "%Y%m%d")
1207180800
>
... 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.
... also working fine on Solaris.
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...