[ZCM] [ZC] 491/ 6 Comment "DateTime default timezone wrong in some locations"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #491 Update (Comment) "DateTime default timezone wrong in some locations"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/491

==============================================================
= Comment - Entry #6 by limi on Jul 10, 2006 2:10 pm

This is a Zope bug, not an OS bug. All our Australian friends have this problem all the time. Could we have this re-opened, please?
________________________________________
= Comment - Entry #5 by Zen on Jul 10, 2006 1:50 am

This issue has never been dealt with AFIK, and the original reason for rejecting the bug is incorrect - Zope2 was assuming that timezone abbreviations are unique which is incorrect, and there are no standards that attempt to make it so. Timezones are political decisions and are not determined by anyone in the IT industry.

That said, EST is the correct abbreviation for both Eastern Standard Time and Eastern Summer time in Australia according to the database used by almost all Unix systems. 
________________________________________
= Comment - Entry #4 by bleve on Jul 10, 2006 12:45 am

Did anything ever get done about this?  I've a zope 2.9.3 server that seems to exhibit a broken timezone problem, and my timezone is Australia/Melbourne - but it shows as EST

________________________________________
= Comment - Entry #3 by Zen on Jan 17, 2003 8:57 pm


> There are unique international standards for what to call your timezones.
>   If Zope doesn't support them, then that is a bug with Zope. If your unix
>   system doesn't support, then that is also a bug, but not with Zope. :)

If there actually is an ISO or IEEE standard on this, Countries and other regions do not follow it. The operating systems implement the realities in the countries. This behaviour is common to Solaris 2.8, Redhat 7.2 and OS X 10.2 and probably
every other Unix that uses zoneinfo. I think this issue needs to remain open.
________________________________________
= Reject - Entry #2 by regebro on Jan 17, 2003 6:50 am

 Status: Pending => Rejected

There are unique international standards for what to call your timezones. If Zope doesn't support them, then that is a bug with Zope. If your unix system doesn't support, then that is also a bug, but not with Zope. :)


________________________________________
= Request - Entry #1 by Zen on Jul 26, 2002 7:08 pm

DateTime currently relies on just time.tzname to determine the default timezone. Unfortunatly, these strings are not unique. This is the case in Australia, and possibly other areas in the world, on many Unix based systems:

  >>> time.tzname
  ('EST', 'EST')
  >>> time.timezone
  -36000
  >>> time.altzone
  -39600

A possible solution would be to insert a check. After retrieving the timezone strings, check time.timezone to see if the offset in seconds matches what is expected. If not, convert the offset to a GMT+XX string and use that as the local timezone. This solution would also future proof the DateTime library to some extent, as well as making Australian's happier. Current workarounds do not handle daylight savings issues.

==============================================================