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

[James Busser]

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 !