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)