[Monotone-devel] Notes on time and date handling

[Zack Weinberg]

As I mentioned this morning, I have replaced all our uses of
boost::date_time with bespoke logic; in the process I got to take a
good hard look at what we do with dates and why.

To first order, the only things we do with dates are: take them from
somewhere and stuff them into date certs; take them back out of date
certs and present them to the user.  They are stored as ISO 8601
format strings in date certs (YYYY-MM-DDThh:mm:ss) and so it was
easiest to use those strings as our canonical internal representation.
(The other logical choice - and we might want to revisit this to deal
with the things I discuss below - would be a format equivalent to
"struct tm", although I would recommend not actually using "struct tm"
because it has some weird properties that we should hide from most of
the code.)

There are three different kinds of "somewhere", corresponding to the
three static factory functions in dates.hh:

- from the system clock: date_t::now().  This can be trivially
implemented in terms of C90 routines, and we don't have to worry about
the time zone, yay.

- from CVS conversion: date_t::from_unix_epoch().  Unfortunately, all
the world does not use the Unix epoch, so we can't do this in terms of
C90 routines.  This was by far the hardest piece of code to write.  I
now have rather more sympathy for what McVoy did in Bitkeeper, i.e.
code a static table of year-starting seconds, file an internal bug
report saying that this would break in 2038, and assign said bug
report to his infant son.  What we do here is not entirely correct:
CVS date stamps are in *local* time, not UTC.  Which local time, I
hear you cry?  The server's.  Whatever that was.  I have a suspicion
that if you ever had two users with direct write access to the
repository and different TZ settings, you'd have inconsistent date
stamps in the repo.  All this is by way of saying that we probably
don't want to try to change what we do with  date stamps from CVS.

- from the --date option: date_t::from_string().  This is the primary
place I think we might want to change things around.  We currently
accept only full ISO 8601 date strings as arguments to this option
(with a few minor variations) and they are interpreted as UTC rather
than local time.  It would be more user friendly to accept a wider
variety of date formats and treat them as local time (converting to
UTC of course - but that's not that hard, thanks to mktime()).  The
trouble is that there's such a bewildering variety of date formats to
consider.  FSF has a "getdate" module in their "gnulib" helpful
utilities collection, and I would certainly prefer to use that than to
roll our own, except that it's written as a Yacc parser, sigh.

The other thing I think we should consider changing is date *output*.
We currently take those ISO 8601 strings straight from the date certs
and splat them into log output (or whatever).  It might make sense to
convert them to local time and/or to the user's locale's date format.
This would not be hard to implement.

zw