time_t - When does it break?

[Stuart D. Gathman]

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.  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.