Re: Less is more

>> Not so.  The amount of work in decoding an integer (say a UNIX-style
>> time_t) to a date is approximately equal to the amount of work in
>> parsing a RFC822 style date, and it's at least as easy to botch
>> up the decoder as to botch the RFC 822 date parser.  The amount of
>> work in encoding an integer date from yyyy/mm/dd/hh/mm/ss form
>> is more than the amount of work in encoding that same quantity
>> in RFC 822 format - and it's harder to get that encoder right.
>
> Are you saying that
>      yyyy/mm/dd/hh/mm/ss -> integer
> is more work than
>     RFC 822 -> integer
>

no, I'm saying that if you already have year, month, day, etc. as 
separate quantities, it's fairly easy to generate 822 date strings (the 
chief difficulty is in getting the timezone offset right).  OTOH it's 
somewhat harder to generate 822 date strings if you start with, say, 
the number of seconds offset since some epoch.

(and for those who think we could just use UNIX time_t  - what happens 
in 2038?  and if you pick a different epoch than 1-Jan-1970, you can 
still run into those boundary conditions if you don't code things very 
carefully.  for that matter, it's a bit tricky to get the time_t to 
struct  tm encoding/decoding working right all the way up to 2**31 
seconds, because you have to write code that either doesn't overflow or 
that works correctly when it does overflow)