[Top][All Lists]
[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
- Re: [Gnumed-devel] dob bug, (continued)
Re: [Gnumed-devel] dob bug, Sebastian Hilbert, 2011/03/09
Re: [Gnumed-devel] dob bug, Sebastian Hilbert, 2011/03/10
Re: [Gnumed-devel] dob bug -more info,
Sebastian Hilbert <=
Re: [Gnumed-devel] dob bug - workaround, Sebastian Hilbert, 2011/03/17
Re: [Gnumed-devel] dob bug -more info, Sebastian Hilbert, 2011/03/17
Re: [Gnumed-devel] dob bug -more info, Karsten Hilbert, 2011/03/17
Re: [Gnumed-devel] dob bug -more info, Sebastian Hilbert, 2011/03/18
Fwd: Re: [Gnumed-devel] dob bug, Sebastian Hilbert, 2011/03/17
Fwd: Re: [Gnumed-devel] dob bug, Sebastian Hilbert, 2011/03/17