newLISP Fan Club

Forum => Anything else we might add? => Topic started by: cormullion on April 12, 2008, 03:08:15 AM

Title: parse-date problems
Post by: cormullion on April 12, 2008, 03:08:15 AM
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...
Title:
Post by: Lutz on April 12, 2008, 04:06:35 AM
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.
Title:
Post by: cormullion on April 12, 2008, 04:28:42 AM
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...
Title:
Post by: cormullion on April 12, 2008, 04:46:58 AM
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
>
Title:
Post by: Lutz on April 12, 2008, 04:53:19 AM
... 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.
Title:
Post by: Lutz on April 12, 2008, 05:03:31 AM
... also working fine on Solaris.
Title:
Post by: cormullion on April 12, 2008, 05:47:19 AM
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...