[Top][All Lists]

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

Re: [Gnumed-devel] Handling of time hh:mm:ss in dob (date of birth)

From: James Busser
Subject: Re: [Gnumed-devel] Handling of time hh:mm:ss in dob (date of birth)
Date: Sat, 23 Aug 2008 11:07:52 -0700

What I write below may be moot, if I correctly interpret from Karsten's latest reply that he agrees that time should be split out and it is a simple question of working within the current constraint of "date with time stamp" until it has been possible to make the change.

I figured I would post it anyway, in case it informed anything further.

On 23-Aug-08, at 5:18 AM, Jerzy Luszawski wrote:

I certainly do not object to modeling reality and storing the "truth", but IMHO it will be easier when date and time are stored in separate field. This way we do not loose any information, but handling is easier.

Can we work from the purpose(s) that the date of birth serve(s)?

1. It could be possible to specify exactly the moment of birth, but does anyone argue a need to reference that exact moment?

2. What are the downsides of maintaining a time field in a separate field, only for those patients for whom the information is (a) available and is (b) of any actual interest?

3. If a dob field is maintained as date-only, the time zone would (I think) be moot. It is true that at any one moment, the date can have either of two values in the world. But date of birth is used primarily as an identity and reference check, without regard to the time of birth. If someone were born in their local time zone on August 23 2008 at half past midnight, while under daylight savings time, it is true that if this were entered or considered "not" under daylight savings time and perhaps under UTC the date could be August 22 2008 (at 2330h). However, in all instances, I expect the record of birth would always want the date of birth to be captured and to stand permanently as August 23. In other words, for the purpose of recording, the date of birth yyyy mm dd at whatever time the birth happened to occur locally is supposed to stand as the date of birth irrespective of UTC. (*)

GNUmed has been mostly careful about not permitting the storage of information that is ambiguous or not truthful. Therefore, within data of birth, the storage of a time that is not the actual time of birth creates a problem. It sounds like it is being argued that a fabricated time (despite that it bears no relation to the patient's reality) must be entered in order to assure desired behaviour. I think we need a clearer exposition of the problem.

(*) if we ever got worldwide agreement that date and time of birth were important and therefore important to coordinate with UTC we could revise GNUmed. I suspect such worldwide agreement would frighten me !

reply via email to

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