15:11 <theartisan> raggi: a friend just pointed out ruby 1.9 parses 2012-012 and 2012-12 as the same ISO date, the former being 12 jan 2012 and the latter december 2012, if were doing any time based validation of certs then that becomes a problem right? cant trust ISO formatted dates?

15:12 <theartisan> would need a trustable date parsing library

17:14 <drbrain> theartisan: X.509 doesn't work that way and I doubt PGP would either

17:16 <theartisan> was just a worry about any dates serialized as iso format

17:19 <drbrain> X.509 uses ASN.1 for all serialization

17:20 <theartisan> does rubygems use iso dates anywhere else in the system?

17:21 <drbrain> I'm not sure what YAML uses for its date format

17:21 <drbrain> but that is derivative

17:21 <theartisan> yaml uses ISO iirc

17:21 <theartisan> its not going to be much of a problem in ruby only environments as everything will suffer the same bug

17:22 <theartisan> but in a mixed environment (raggi's new non ruby mirror?) it could be intresting

17:24 <theartisan> best to maybe only use epoch times in any serializations?

20:19 <manveru> theartisan: only Time.parse is doing silly stuff

20:20 <manveru> theartisan: using Time::iso8601 or Time::rfc2822 or Time::strptime fixes that

20:22 <theartisan> http://tommorris.org

20:22 <theartisan> http://tommorris.org/posts/8114

20:22 <theartisan> thats better

20:26 <theartisan> > Date.iso8601('2012-12') => #<Date: 2012-01-12 ((2455939j,0s,0n),+0s,2299161j)>

20:27 <theartisan> that should be 2012-12-01 at least

20:28 <theartisan> if you manufacture a yaml payload like that, the ruby code could be 12 months out from a more complient one...

21:18 <raggi> theartisan: anyone who uses a dynamic parse library for dates shouldn't be anywhere near this stuff...