gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] dob bug -more info


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] dob bug -more info
Date: Thu, 17 Mar 2011 11:35:08 +0100
User-agent: KMail/1.13.6 (Linux/2.6.37.3-16-default; KDE/4.6.0; i686; ; )

Am Donnerstag, 10. März 2011, 10:09:14 schrieb Karsten Hilbert:
> On Thu, Mar 10, 2011 at 08:28:21AM +0100, Hilbert, Sebastian wrote:

I am finally able to reproduce this.

When setting the languge to EN (India) and timezone Asia/Kolkata

I am getting as default in the dob field:

for 17th March 2011:

Monday172011October20112011

:-)

Trying to isolate it now.

Sebastian




> > >From the bootstrap log (below) it looks like it tries to set India
> > >standard
> > 
> > time which cannot be set (by whom?).
> 
> By GNUmed to be used by PostgreSQL.
> 
> > It then maps to posix/Israel.
> > 
> > 'client system time zone detected as equivalent to [posix/Israel]'
> 
> Grepping postgresql.conf for India:
> 
> #timezone_abbreviations = 'Default'     # Select the set of available time
> zone # abbreviations.  Currently, there are
>                                       #   Default
>                                       #   Australia
>                                       #   India
>                                       # You can create your own file in
>                                       # share/timezonesets/.
> 
> Try setting this.
> 
> > 2011-03-05 23:07:44  DEBUG     gm.datetime
> > (/var/lib/gnumed/Gnumed/pycommon/gmDateTime.py::init() #170): ISO
> > timezone: [05:30:00.00] (taken from mx.DateTime.now().gmtoffset())
> 
> That's the offset.
> 
> > 2011-03-05 23:07:44  DEBUG     gm.db
> > (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__detect_client_timezone()
> > #266): trying to detect timezone from system 2011-03-05 23:07:45  DEBUG 
> >    gm.db (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__expand_timezone()
> > #247): [IST] maps to [posix/Israel]
> 
> That is one possible timezone name for this offset.
> 
> > 2011-03-05 23:07:45  DEBUG     gm.db
> > (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__detect_client_timezone()
> > #283): candidates: [u'IST', u'posix/Israel']
> 
> Those are all the names GNUmed was able to find in the
> system consistent with 5:30 offset.
> 
> > 2011-03-05 23:07:45  DEBUG     gm.db
> > (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__validate_timezone() #193):
> > validating time zone [IST]
> 
> It checks whether PostgreSQL can use this time zone.
> 
> > 2011-03-05 23:07:45  WARNING   gm.db
> > (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__validate_timezone() #214):
> > time zone [IST] is not settable
> 
> It cannot even set it (see above).
> 
> > 2011-03-05 23:07:46  DEBUG     gm.db
> > (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__validate_timezone() #193):
> > validating time zone [posix/Israel]
> 
> So it checks the next one.
> 
> > 2011-03-05 23:07:46  INFO      gm.db
> > (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__validate_timezone() #203):
> > time zone [posix/Israel] is settable
> 
> That one IS settable.
> 
> > 2011-03-05 23:07:46  INFO      gm.db
> > (/var/lib/gnumed/Gnumed/pycommon/gmPG2.py::__validate_timezone() #209):
> > time zone [posix/Israel] is usable
> 
> And it even works (for PostgreSQL anyways).
> 
> Does it make a difference as to which date is actually
> entered into the DOB control ?
> 
> Karsten




reply via email to

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