Page 1 of 1
parse-date problems
Posted: Sat Apr 12, 2008 10:08 am
by cormullion
I'm having trouble understanding
parse-date's limitations.
Code: Select all
>(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...
Posted: Sat Apr 12, 2008 11:06 am
by 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.
Posted: Sat Apr 12, 2008 11:28 am
by cormullion
Further research shows it works on newLISP 9.2 on BSD:
Code: Select all
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...
Posted: Sat Apr 12, 2008 11:46 am
by cormullion
It's OK on 9.2 (well, 9.1.9) on MacOS X:
Code: Select all
newLISP v.9.1.9 on OSX UTF-8, execute 'newlisp -h' for more info.
> (parse-date "20080403" "%Y%m%d")
1207180800
>
Posted: Sat Apr 12, 2008 11:53 am
by 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.
Posted: Sat Apr 12, 2008 12:03 pm
by Lutz
... also working fine on Solaris.
Posted: Sat Apr 12, 2008 12:47 pm
by 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...