parse-date problems

cormullion · Post by **cormullion** » Sat Apr 12, 2008 10:08 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...

Lutz · Post by **Lutz** » Sat Apr 12, 2008 11:06 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.

cormullion · Post by **cormullion** » Sat Apr 12, 2008 11:28 am

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...

cormullion · Post by **cormullion** » Sat Apr 12, 2008 11:46 am

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
>

Lutz · Post by **Lutz** » Sat Apr 12, 2008 11:53 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.

Lutz · Post by **Lutz** » Sat Apr 12, 2008 12:03 pm

... also working fine on Solaris.

cormullion · Post by **cormullion** » Sat Apr 12, 2008 12:47 pm

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...