[Zope] FW: [Zope] Problems requesting SQL date fields

[Brian Hooper]

I suggested this before on the list but didn't get any response - 
wouldn't it be better to find out the timezone via time.timezone and then 
convert the value to some sort of consistent representation?

This is a safer bet, especially for Zope to run problem-free on non-POSIX
compliant OSs (like Win95/98 or NT)

--Brian Hooper <brian@garage.co.jp>


"F.G. Hoekstra" <hoekstra@fsw.LeidenUniv.nl> wrote:

> 
> 
> >
> > Without more info this suggestion is just a shot in the dark, but as Brian
> > Hooper wrote a few days ago, here in Tokyo he and I recently had a hell of
> > a time with SQL date fields. (If you've already seen his post and it's not
> > relevant, apologies - and please disregard the rest of this...)
> >
> > We had no problem inserting datetime values into MySQL, but when
> > requesting
> > the values Zope wasn't able to parse them. We finally figured out
> > that NT 4
> > was returning 'Tokyo Standard Time' as the time zone value, which Zope
> > didn't recognize and couldn't deal with. Thus if you're in
> > Germany and have
> > your system time zone set appropriately, this _may_ be the cause of your
> > trouble as well. I've included part of Brian's post below with the fix -
> > if, in case, this is the cause of your ills.
> >
> 
> A few days ago I delved into the DateTime modules and the problem may be
> more complicated in Western Europe because
> 
> 1. neither the DateTime module, nor the DateTimeZone have entries for Middle
> European Time (MET, which is the time of most of the countries of the
> European Community, including Germany). They have entries for Poland and
> GB-Eire and for Japan. The DateTimeZone._data dictionary entries were rather
> cryptic (at least to me), which makes it difficult to add one.
> 2. Depending on the language version of Win95 (which I work with) and
> probably W98 and NT as well, a different version of the timezone name:
> time.tzname module returns ('W. European Standard Time', 'W. European
> Daylight Time') in the English version and something like ('West Europese
> Standaardtijd', 'West Europese Zomertijd') in the Dutch version, and
> probably something else in the French, German, Spanish etc version.
> 
> The result of all this is an empty timezone in the DateTime representation
> (DateTime('1999/02/26 09:23:47.4 ')), which makes it unparsable to the
> DateTime module.
> 
> Hope this makes thing clearer. But I do not know how to solve this. Probably
> an entry for MET in the DateTime modules would be the most important step.
> 
> 
> Rik Hoekstra
> 
> > - Jay
> >
> > >Brian Hooper <brian@garage.co.jp> wrote:
> > >
> > >MySQL select queries were mysteriously failing with a parse
> > error in RDB.py,
> > >related to not being able to parse a DATETIME field.
> > >
> > >After looking at DateTime.py and concluding that DateTime should
> > be able to
> > >parse virtually anything ;-), we were initially very puzzled as
> > to the cause
> > >of the parse error.  However, after eliminating everything else we could
> > >think of, we finally found that it was the fact that NT was returning the
> > >value 'Tokyo Standard Time' as the timezone for our machine - a
> > value which
> > >is not listed in the _zmap in DateTime - so, DateTime was failing here:
> > >
> > >                # Current time, exp in specified timezone
> > >                t,tz=time(),self._tzinfo._zmap[lower(arg)]
> > >
> > >We added the mapping 'tokyo standard time':'Tokyo' to _zmap,
> > restarted Zope,
> > >and now everything's working fine.
> 
> 
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
>