Re: [Monotone-devel] Monotone displays commit times in UTC, not local time

[Zack Weinberg]

On Thu, Jun 5, 2008 at 10:00 AM, Matthew Nicholson <address@hidden> wrote:
> Zack Weinberg wrote:
>> I wouldn't call it _desirable_, but it is the expected behavior.
>> Dates are stored as strings in the database, in exactly the format you
>> see them, in UTC.  When they're printed, we just print them out as
>> strings.  This is because doing a time zone conversion is fraught with
>> portability issues.
>
> Boost.DateTime can parse the exact string that we store in the database and
> convert it to local time.  It should be an easy patch to write.  Not sure
> how that would affect performance or if we are willing to link with boost
> date_time.

We used to use Boost.DateTime and we got rid of it, because all
components of boost that involve object libraries are way more trouble
than they are worth.  Please don't bring it back.

Also, we already have code to parse the strings we store in the
database and spit out 'struct tm's.  The problem is that the only
reliable way to get a time in the local time zone is the localtime()
function, which takes a time_t, and there is no portable way to
convert a 'struct tm' representing UTC to a time_t.  mktime(), which
is standard, interprets the 'struct tm' as local time.  *BSD and glibc
have timegm(), but that's "not in any standard" according to the
manpage; I should file a bug against the Linux manpages, their
suggested "portable replacement" for timegm ... isn't.  gnulib offers
an implementation of timegm, but it assumes the Unix epoch, which is
no good if you want to be able to pass the return value into the
system's localtime.  Does your head hurt yet? ;-)

(On a casual glance at Boost.DateTime documentation, it appears to
reimplement the entire time zone mechanism itself.  While I don't
blame them for throwing up their hands at the C library's inadequate
interfaces, that means it's pretty much guaranteed to disagree with
the system in at least some cases, especially as it *doesn't* seem to
use the Olson timezone dataset that everyone else uses.  That dataset
gets dozens of updates per year...)

(As an aside, this sort of thing is why I'm not a fan of the Boost
header-only libraries either.  Case in point: Boost.Format
deliberately implements a formatting spec that is subtly incompatible
with printf()...)

> P.S. I noticed this issue too, and it is kind of annoying.  It makes using
> the dates in monotone some what difficult.

Now y'all have got me thinking about it, I might see what I can do,
despite the headaches above.

zw