time_t - When does it break?
Stuart D. Gathman
stuart at gathman.org
Thu Jul 17 13:20:13 EDT 2008
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
> > simply works around the bug for 90% of the use cases. From the
> 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
> types to get days between dates. (No dividing by 24*60*60 doesn't
> - 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. 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
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.
More information about the gnucash-devel