time_t - When does it break?

[Charles Day]

On Thu, Jul 17, 2008 at 10:20 AM, Stuart D. Gathman <stuart at gathman.org>
wrote:

> Charles Day wrote:
>
>> On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman <stuart at gathman.org<mailto:
>> stuart at gathman.org>> wrote:
>>
>>    Nathan Buchanan wrote:
>>    > I agree that the 00:00 timestamp is a bug, but the 12:00Z or
>>    10:01:00Z
>>    > simply works around the bug for 90% of the use cases. From the
>>    perspective
>>    >
>>    Not only that, but if you force the time of day in each timestamp to
>>    12:00Z, then you no longer have a timestamp, but a complicated and
>>    difficult to use date type.  You can't even subtract these ersatz
>>    "date"
>>    types to get days between dates.  (No dividing by 24*60*60 doesn't
>>    work
>>    - don't forget DST, etc).
>>
>>
>> I would be interested in your reaction to my RFC on a timestamp
>> implementation. Other than ease-of-use issues, is there a situation in which
>> the RFC's proposed way of using timestamps would be detrimental compared to
>> using a date alone?
>>
> The way gnucash works currently is perfectly fine - *provided* you only
> ever use one timezone.  This covers the vast majority of users.  The systems
> I have had to repair date logic for had worked perfectly for years - but
> then the company expanded to have branches in multiple timezones.  Suddenly,
> all hell breaks loose.   Imagine for a moment that gnucash didn't store
> currency with transaction amounts.  This works perfectly fine as long as you
> only ever use one currency.  This would be fine for almost all US users, for
> instance.  Now imagine trying to support multiple currencies without
> actually storing the currency with the amounts.  :-)
>
> As I understand your proposal, it would use localtime "as if" it were GMT
> time.  I.e., take the local time, replace the timezone with GMT, and convert
> to time_t.


The basic idea is that in an account register the user enters a date and
time of day (or accepts the default time of day) in terms of that account's
timezone.  When you view that transaction in another register that has been
set to a different timezone, the date and time is displayed accordingly. For
example, if you specify July 7, 2008 13:03 in a UTC+11 register, then
viewing that transaction in a UTC-7 register would show July 6, 2008 18:03.
(If I did the math right.)

There is no pretending involved. I suggest that GnuCash would write the
timestamp to files in UTC, but only by converting first (July 7, 2008
02:03). GnuCash really could write the date and time to the file in any time
zone, as long as the time zone was saved too.

I have used that technique myself in repair work.  It solves date
> compatibility between timezones.  You can recover the actual timestamp if
> you can infer the timezone somehow.
> However, it requires lots of comments to explain to code maintainers so
> they don't screw things up.  "No, it is not a mistake when we replace the
> timezone with GMT..."  I created a new type for such "timestamps" to help
> prevent confusion with real time_t.   It still is complicated to do basic
> date arithmetic.  The only redeeming value is that you can drop it into an
> existing database without changing too much code if you do it right.


> If you have to anything funky to time_t to make it work right (force time
> of day to 12:00Z, pretend localtime is really GMT, etc) because what you
> really needed was a date type, and you don't have to interface with existing
> databases or code that can't be fixed, then the sensible thing to do is use
> a date type.
>

-Charles