Re: [Gnumed-devel] re timezones

[Jim Busser]

On Apr 8, 2004, at 9:33 PM, Elizabeth Dodd wrote:

> On Thu, 8 Apr 2004 03:17, Karsten Hilbert wrote:
> > ...gmPG sets the default client time zone upon connection creation.
> >
> > ...PG optionally stores timestamps with a time zone qualifier
> >
> > ...input ...submit local time ...converted to UTC for storage.
> >
> > ...what about:
> >
> > 2003/24/08 13:45   Kirk involved in traffic accident, oversaw
> >                    elderly pedestrian at Fourth Street, Melbourne
> >
> > Now, where's the problem ? Well, 13:45 is *my* CEST local
> > time. However, the accident happened some 12 hours earlier, at
> > 1:45am AU local time ! The time displayed in my client will
> > never hint me into thinking of checking night vision on Kirk. He
> > may have selective blindness/tunnel vision at night.

> So Captain Kirk rammed his space ship into a pedestrian at 0045 hrs 
> Melbourne
> time because he was drunk or his cataracts messup his night vision - 
> but the
> computer doesn't timestamp this at the time of incident; it timestamps 
> it
> when I make the note about it.

By timestamp I assume we refer to capture and writing of the server 
date and time, per its "system clock" (or else the date & time of the 
client machine). If so, then through timestamp

- PG will capture the date & time of any RECORD's creation (or 
modification)
- such a timestamp will only accurately depict a clinical event when 
the client was in use during the event
- dates & times of clinical events will otherwise be captured as either:
--- free text (in which the event location ought to be captured hence 
addressing the ambiguity) or as
--- a user-coded date & time

I can imagine inputting a clinical event's actual date (where known) 
into a date field, such as the date on which an illness began or on 
which a hospitalization occurred or a procedure was performed, but I 
might only in special cases code a time into a time field --- maybe 
birth and death and in billing, wherein the start and end times of a 
service may have to be specified. I may also enjoy a premium 
(surcharge) for services performed after hours. For all of these, the 
time zone occupied by the patient at the time of the event occurred (or 
the service was delivered) is the one to capture and would always be 
local except where the patient had moved across time zones.

Suppose in the latter case an Australian patient holidays to Honolulu 
and, on their last day (with insurance expiring), receives care 
recorded in Gnumed as having been given April 9 at 4pm (though this 
would be 12:30pm April 10 on Lord Howe Island, Australia). Six hours 
later, the patient boards a 12-hour  "red eye" flight to Australia, and 
arrives at what is now 6:30 am on April 11 in Australia and a few hours 
later sees his GP who, for the sake of argument, can access the 
Honolulu Gnumed record. The GP will either see that the care, viewed 
relative to the point of delivery, had been given April 9 ("looks like 
2 days ago") or else April 10 ("looks like yesterday"). If a resolution 
of this were important, I might like to view it from the context in 
which it was delivered i.e. to be told/shown the date/time according to 
the time zone in which the event occurred, but also to have it 
expressed as # days / hours ago.