Re: [Gnumed-devel] dob bug - workaround

[Sebastian Hilbert]

The dob problem occurs when locale 

en_IN is set instead of en_US or other.

This can be fixed by changing the locale to eg en_US (don't forget to log out 
and in for this change to be effective)

However en_IN influences a few things such as currency so either we find a way 
to work around it in GNUmed or find the defect in wxpython/GTK 

Sebastian



> 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
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel