Re: Bug #630: date/time storage problem: timestamp parsed

> > Good call Tom. ... I'm going to file a PR w/ FreeBSD. I know
> > the attached patch is something of a hack, but it works. I'm not
> > totally wild about altering the original time object, but I don't
> > know that I have a choice in this case. Does anyone switch
> > timezones and only adjust their clocks by anything other than
> > 60min? I seem to recall that happening in a few places, but the
> > patch isn't any worse than where we are now. ::shrug:: This look
> > like an okay patch?
>
> Yuck. You are trying the right things, but I'm not sure that we
> should allow mktime() to fail for special cases like this. Falling
> back to GMT (a potential offset of up to 12 hours from what was
> intended by the user) is (perhaps) unacceptably ugly, particularly
> for recent/current epochs which would be reasonably expected to
> behave correctly.
>
> I'm inclined to test for an error return from mktime(), or to test
> it as an ASSERT(), and then throw an error, rather than passing
> along garbaged-up values.
>
> Comments?

I thought about throwing an exception but noticed a few lines down
that the code was returning GMT on failure. When in Rome, do as the
Romans do. :~) I personally think that ASSERT should be called after
the 2nd mktime() fails but think that calling ASSERT would break
existing applications though maybe not: I've just had a 6hr crash
course in this code and don't quite have the incite to say one way or
another.

FWIW, I've lobbed something off to the FreeBSD crowd asking if
mktime() should be updated in the system libraries.... but don't think
that'll fix things "soon enough." -sc

--
Sean Chittenden