Derek Atkins warlord at MIT.EDU
Wed Jul 16 17:17:56 EDT 2008

Quoting "Stuart D. Gathman" <stuart at gathman.org>:

>>> I agree, 1200UTC would prevent time zones from shifting transactions to
>>> another day. That would be a better default than 0000 local. That 
>>> could work
>>> for default price times as well (see but 541970).
> Storing timestamps for dates *would* be just more information that could
> be ignored (and hence harmless) *if* the timestamps included a critical
> piece of information currently missing: the timezone.  The XLNDate type
> requires a timezone to do its conversions.  When the timezone is not stored
> in the database (the usual case - hence the problems), I infer the timezone
> by other means and supply it.

You haven't looked at the data file recently, have you?  Here's
an example from mine:

      <ts:date>2008-04-10 18:02:00 -0400</ts:date>

> A GMT timestamp alone doesn't tell you what date it is - you need the 
> timezone
> to compute that.

Actually, except for GMT-12 or GMT+12, no, you do NOT need the time zone
to figure out the date from 1200 UTC.   However as I've said now three
times, GnuCash doesn't use 1200 UTC currently, it uses 0000 local, which
(as I've said a half dozen times) I consider a bug that should get fixed.

> A Localtime timestamp alone doesn't tell you what time it is - you need the
> timezone to compute that.

This depends on your definition of "localtime".  Usually you can infer
the local timezone from the environment.  So if I have a localtime
integral value in memory I can either convert it to UTC and store it
as UTC with no timezone (on the assumption that the data storage
mechanism defines that datum as "timestamp in UTC", or I can store
it in localtime with the local timezone information (which is what the
current XML backend does -- see above).

> So the bottom line is, storing just timestamps *is* missing crucial
> information.   If storing just the actual date doesn't sit with people, then
> store a *complete* time and date - which includes timezone.

True, you do need a timestamp plus a timezone.  HOWEVER, there are
cases where the timezone can be inferred implicitly, and that's still

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list