Stuart D. Gathman
stuart at gathman.org
Wed Jul 16 16:37:49 EDT 2008
On Wed, 16 Jul 2008, Phil Longstaff wrote:
>>>> It is actually the case that (depending on financial policies) storing
>>>> the actual time could present problems.
I've had to deal with many such problems in a commercial system using
timestamps for dates. I ended up creating an XLNDate type to convert the
stored timestamps to/from dates (non-trivial to do it right).
>> 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.
A GMT timestamp alone doesn't tell you what date it is - you need the timezone
to compute that.
A Localtime timestamp alone doesn't tell you what time it is - you need the
timezone to compute that.
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.
Stuart D. Gathman <stuart at bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
More information about the gnucash-devel