[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Date of birth default times all seem to be 11:11

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Date of birth default times all seem to be 11:11
Date: Sun, 17 Jul 2011 10:58:33 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Jul 15, 2011 at 11:40:27AM -0700, Jim Busser wrote:

> What you originally attempted
>       timestamp with timezone
> and setting time (when not entered) to 0:00:00 sounds most appropriate.

It is not because it will near guarantee that we see the day
shift. While the shift is technically correct it will
confuse users no end.

> A date of birth, we might agree, is definable instant (moment) in time on 
> planet earth.

"date ... is .. time on planet earth" is a contradiction.

As time is defined (even if extended to date) in relation to
where on planet earth we are (actually - tied to what we see
of the sun when) the time *label* is shifting.

Sure, it is still the same absolute, fundamental instance -
but the label (as in what the clock displays) changes.

> Even though it is possible to make *this* column date-only (no time zone),
> I am worried a bug will still bite us on other datetimes!

No, those can shift and everything's fine.

It's only the DOB because that's often rather than not from
a non-local time zone while most other datetime are from the
local timezone and thus will display just fine no matter how
the computer shifts them internally.

> Can we figure out what is going on? Note that I get
> different results from the same data set when I run psql
> compared to when I query from the Reports plugin…

Of course, because psql hasn't been told which time zone you
are in.

> The difference in the output is not even just a uniform
> "shift", the difference is *variable*. Note how from the
> psql output, only the first two share the same UTC offset (
> -08), whereas in the results of the query returned by the
> Reports plugin, the first *three* share the same offset and
> it is different from the psql results ( -09).

Exactly. We want to avoid this shift alltogether regarding
the *date* of birth and thus make it a date column.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]