Thread: BUG #6638: Casablanca timezone is wrong
The following bug has been logged on the website: Bug reference: 6638 Logged by: David Chuet Email address: dchuet@odotech.com PostgreSQL version: 9.0.7 Operating system: Windows 7 x64 Description:=20=20=20=20=20=20=20=20 Using Postgresql command : ------------------------------------------ SELECT * FROM pg_timezone_names ------------------------------------------ We get for Africa/Casablanca, timezone equal to WET with no DST. This is not true from 2010. See Wikipedia, for Morocco: Time zone WET (UTC+0) Summer (DST) WEST (UTC+1)(May 2nd to August 7th) So, I cannot set correctly the DateTime for an install in Morocco.
dchuet@odotech.com writes: > We get for Africa/Casablanca, timezone equal to WET with no DST. > This is not true from 2010. > See Wikipedia, for Morocco: I wouldn't necessarily trust Wikipedia for that. We use the IANA (nee Olson) timezone database. If you think the information in that is wrong, you should take it up with the upstream maintainers: http://www.iana.org/time-zones As far as I can tell from a quick look in their mailing list archives, the timezone data shipped with 9.0.7 is correct for Morocco through 2011. It does not know about the 2012 DST law that was just published a few weeks ago, but unless you can provide use of a time machine, there's not a lot we can do about that. We customarily update to the latest timezone data files available from IANA whenever Postgres update releases are made. If you are in a bigger hurry than that, you can get the latest tzdata files from the above-mentioned page and drop them into the timezone directory in your installation. regards, tom lane
On 14.05.2012 18:21, dchuet@odotech.com wrote: > We get for Africa/Casablanca, timezone equal to WET with no DST. > > This is not true from 2010. > See Wikipedia, for Morocco: > > Time zone WET (UTC+0) > Summer (DST) WEST (UTC+1)(May 2nd to August 7th) PostgreSQL uses the timezone data from the so-called Olson library. See http://www.twinsun.com/tz/tz-link.htm. Looking at the upstream library, this is fixed in the most recent version (tzdata2012c), We will pick up that change in the next PostgreSQL minor release, ie. 9.0.8 for the 9.0 series. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
VGhhbmtzIGd1eXMgZm9yIHlvdXIgcHJvbXB0IHN1cHBvcnQhDQpJJ20gZ29p bmcgdG8gdXBkYXRlIE9sc29uIGxpYnJhcnkgb24gdGhlIGNvbmNlcm5lZCBj b21wdXRlciB1c2luZyB0aGUgbGF0ZXN0IGZpbGVzLg0KDQpUaGFua3MgYWdh aW4uDQoNCkRhdmlkIENodWV0DQpPZG90ZWNoIGluYy4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhlaWtraSBMaW5uYWthbmdhcyBb bWFpbHRvOmhlaWtraS5saW5uYWthbmdhc0BlbnRlcnByaXNlZGIuY29tXSAN ClNlbnQ6IE1heS0xNC0xMiAxMTo1MSBBTQ0KVG86IERhdmlkIENodWV0DQpD YzogcGdzcWwtYnVnc0Bwb3N0Z3Jlc3FsLm9yZw0KU3ViamVjdDogUmU6IFtC VUdTXSBCVUcgIzY2Mzg6IENhc2FibGFuY2EgdGltZXpvbmUgaXMgd3JvbmcN Cg0KT24gMTQuMDUuMjAxMiAxODoyMSwgZGNodWV0QG9kb3RlY2guY29tIHdy b3RlOg0KPiBXZSBnZXQgZm9yIEFmcmljYS9DYXNhYmxhbmNhLCB0aW1lem9u ZSBlcXVhbCB0byBXRVQgd2l0aCBubyBEU1QuDQo+DQo+IFRoaXMgaXMgbm90 IHRydWUgZnJvbSAyMDEwLg0KPiBTZWUgV2lraXBlZGlhLCBmb3IgTW9yb2Nj bzoNCj4NCj4gVGltZSB6b25lIAlXRVQgKFVUQyswKQ0KPiBTdW1tZXIgKERT VCkgCVdFU1QgKFVUQysxKShNYXkgMm5kIHRvIEF1Z3VzdCA3dGgpDQoNClBv c3RncmVTUUwgdXNlcyB0aGUgdGltZXpvbmUgZGF0YSBmcm9tIHRoZSBzby1j YWxsZWQgT2xzb24gbGlicmFyeS4gU2VlIGh0dHA6Ly93d3cudHdpbnN1bi5j b20vdHovdHotbGluay5odG0uIExvb2tpbmcgYXQgdGhlIHVwc3RyZWFtIGxp YnJhcnksIHRoaXMgaXMgZml4ZWQgaW4gdGhlIG1vc3QgcmVjZW50IHZlcnNp b24gKHR6ZGF0YTIwMTJjKSwgV2Ugd2lsbCBwaWNrIHVwIHRoYXQgY2hhbmdl IGluIHRoZSBuZXh0IFBvc3RncmVTUUwgbWlub3IgcmVsZWFzZSwgaWUuIDku MC44IGZvciB0aGUgOS4wIHNlcmllcy4NCg0KLS0gDQogICBIZWlra2kgTGlu bmFrYW5nYXMNCiAgIEVudGVycHJpc2VEQiAgIGh0dHA6Ly93d3cuZW50ZXJw cmlzZWRiLmNvbQ0KDQoNCg0KDQo=