Re: [Gnumed-devel] time zones problem?

[Karsten Hilbert]

Hm, OK, let's see.

GnuMed wants to retrieve a timestamp with time zone (which ?).

> gmPatientHolder.py::_updateUI_wrapper:46):   File 
> "/usr/lib/python2.3/site-packages/pyPgSQL/PgSQL.py", line 804, in 
> typecast<#10-0x0A-lf>    return DateTime.ISO.ParseAny(value)<#10-0x0A-lf>
pyPgSQL uses ParseAny() to convert it. The mx.DateTime docs
are ambigous:

"... only ParseDateTimeUTC() supports timezones ..."

It seems the pyPgSQL people picked the wrong parser.

"... ParseAny() parses any of the supported ISO formats ..."

But this seems to suggest that this also parses the format
for ParseDateTimeAny().

> gmPatientHolder.py::_updateUI_wrapper:46):   File 
> "/usr/lib/python2.3/site-packages/mx/DateTime/ISO.py", line 313, in 
> ParseAny<#10-0x0A-lf>    raise ValueError,'unsupported format: "%s"' % 
> isostring<#10-0x0A-lf>
> gmPatientHolder.py::_updateUI_wrapper:46): ValueError: unsupported format: 
> "1970-05-28 14:00:00+39600"<#10-0x0A-lf>
Which it obviously doesn't.

> I can't seem to reproduce this from the Python console with the exact same 
> query.
I didn't try the *query* but I tested mx.DateTime:

Python 2.1.1 (#1, Sep 24 2001, 05:28:47) 
[GCC 2.95.3 20010315 (SuSE)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import mx.DateTime as mxDT
>>> mxDT.ISO.ParseAny('1970-05-28 14:0:00:00')
<DateTime object for '1970-05-28 14:00:00.00' at 8145480>

 This works. As per docs.

>>> mxDT.ISO.ParseAny('1970-05-28 14:00:00+39600')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/site-packages/mx/DateTime/ISO.py", line 313, 
in ParseAny
    raise ValueError,'unsupported format: "%s"' % isostring
ValueError: unsupported format: "1970-05-28 14:00:00+39600"

 This doesn't. As per one of the statements in the docs.

>>> mxDT.ISO.ParseDateTimeUTC('1970-05-28 14:00:00+39600')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/site-packages/mx/DateTime/ISO.py", line 120, 
in ParseDateTimeGMT
    raise ValueError,'wrong format, use YYYY-MM-DD HH:MM:SS'
ValueError: wrong format, use YYYY-MM-DD HH:MM:SS

 But this doesn't either. This is contrary to any of the
 interpretations of the docs. It may be fixed in a newer
 version of mxDateTime, though.

Now, assuming the "bug" in ParseDateTimeUTC() is fixed now
(someone please verify this?), let's see whether the above
format is a valid ISO timestamp at all ?

This

 http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html

implies that timezones should be defined in "+hours:minutes". Which
"+39600" obviously isn't. So, what is it ? As this timestamp
is provided by PostgreSQL let's see what they have to say
about those matters.

... internally timestamps with timezone are always stored in UTC
... input is converted accordingly
... for output it is always converted to the local timezone
    unless told otherwise
... output can be set to the following styles: ISO-8601, [...]

TODO: we don't set the date/time style in GnuMed yet.


Now, in my 7.1.3 server this

 select dob from v_basic_person

yields "+01" results.

"Show datestyle" yields "ISO/ ..."

Ian, can you check the above points on your server ?

hherb.com has datestyle ISO/DMY on PG 7.4.1 and yields
"...+01" values, too, which seems allowable for ISO.

> I know mxDateTime doesn't support time zones, 
It does, supposedly, with caveats.

> it seems to be choking on the "+39600", but why only inside gnumed?
It also chokes outside gnumed.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346