gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Measurements - adding and abbreviations


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Measurements - adding and abbreviations
Date: Sun, 31 Jul 2011 22:05:46 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jul 27, 2011 at 03:44:16PM -0700, Jim Busser wrote:

> 2) when I reach the field Date
> 
>       - the timestamp is offered by default but even if I type over
> 
>       2011-07-29
> 
> with no time and then tab into the next field, it seems
> 
>       20:11:00.00
> 
> gets auto-appended to the date and the only way I can escape that is to retype
> 
>       2011-07-29
> 
> and (instead of hitting return / enter) to mouse-click out of the date field.
> 
> ??

Well, what happens is this:

GNUmed tries to parse your input. You entered "2011-07-29".
That it translates to "2011 July 29th" and displays
2011-07-29. It also needs a time part and also passes your
input to the mx.DateTime.TimeFromString() parser which makes
of that 20:11 (from 2011, ignoring the rest).

Type 2010-07-29 to observe how it produces 20:10.

Please suggest a saner source of the time when no time is
provided.

Also use 11:11:11.1111 to make it fairly apparent this is an
assumed time ?

Use now().time ?

Now, when the timestamp originated from parsers other than
mx.DateTime it would with certain inputs know the actual
input accuracy and thereby set the display accuracy to that.
Hence it could appear as if only a date was used (w/o time
part) - in which case most often the time part of now() was
used. For the sake of consistence GNUmed will now force the
display accuracy to "minutes" regardless of the parser that
produced the timestamp.

Thanks,
Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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