time_t

[Stuart D. Gathman]

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.