Re: [Maria-developers] MDEV-339 lp:1001340 system_time_zone is wrong on Windows
Hi, Vladislav! On Jun 14, Vladislav Vaintroub wrote:
At file:///H:/bzr/5.5/
revno: 3434 revision-id: wlad@montyprogram.com-20120614122958-bq20w9xbqjw032nk parent: wlad@montyprogram.com-20120613093751-tv67fxuh1qcxm0by fixes bug: https://launchpad.net/bugs/1001340 committer: Vladislav Vaintroub <wlad@montyprogram.com> branch nick: 5.5 timestamp: Thu 2012-06-14 14:29:58 +0200 message: MDEV-339, LP1001340 - system_time_zone is wrong on Windows
On localized Windows versions, Windows uses localized time zone names. Since characters in timezone name can be outside of ASCII range, thus not every client would be able to read variable without loosing information, and even server misinterprets the encoding (it does not try to interpret the encoding).
The fix is to use the UTC offset format "+/-hh:mm" for system_time_zone on Windows, compatible with time_zone values everywhere else. UTC offset format is however not used if TZ environment variable is defined - MySQL documents to handle TZ environment variable in OS-dependent way.
I am not sure I like this idea. UTC offset format specifies a *different* time zone. Not the system one. Timezone that surely produces different results for the historical dates. Original bug report says that system_time_zone value is not a valid MySQL (or POSIX) time zone name. But is it a problem? When time_zone is set to SYSTEM, MariaDB will use OS functions for date/time conversion, and not the data from timezone tables. So it will use the system time zone *exactly*, not UTC offset approximation. And it won't try to look up system_time_zone value in the timezone tables. So, I think, it's quite ok for system_time_zone to have "Westeuropäische Sommerzeit" value. You only need to fix the charset/truncation issue and that's all. Regards, Sergei
"not every client would be able to read variable without loosing information". Since this is a client problem why then a patch in the server? It seems completely wrong to me! Am I missing something? Can we have some examples of clients where this is a problem? Peter Webyog On Thu, Jun 14, 2012 at 9:11 PM, Sergei Golubchik <serg@askmonty.org> wrote:
Hi, Vladislav!
On Jun 14, Vladislav Vaintroub wrote:
At file:///H:/bzr/5.5/
revno: 3434 revision-id: wlad@montyprogram.com-20120614122958-bq20w9xbqjw032nk parent: wlad@montyprogram.com-20120613093751-tv67fxuh1qcxm0by fixes bug: https://launchpad.net/bugs/1001340 committer: Vladislav Vaintroub <wlad@montyprogram.com> branch nick: 5.5 timestamp: Thu 2012-06-14 14:29:58 +0200 message: MDEV-339, LP1001340 - system_time_zone is wrong on Windows
On localized Windows versions, Windows uses localized time zone names. Since characters in timezone name can be outside of ASCII range, thus not every client would be able to read variable without loosing information, and even server misinterprets the encoding (it does not try to interpret the encoding).
The fix is to use the UTC offset format "+/-hh:mm" for system_time_zone on Windows, compatible with time_zone values everywhere else. UTC offset format is however not used if TZ environment variable is defined - MySQL documents to handle TZ environment variable in OS-dependent way.
I am not sure I like this idea. UTC offset format specifies a *different* time zone. Not the system one. Timezone that surely produces different results for the historical dates.
Original bug report says that system_time_zone value is not a valid MySQL (or POSIX) time zone name. But is it a problem? When time_zone is set to SYSTEM, MariaDB will use OS functions for date/time conversion, and not the data from timezone tables. So it will use the system time zone *exactly*, not UTC offset approximation. And it won't try to look up system_time_zone value in the timezone tables.
So, I think, it's quite ok for system_time_zone to have "Westeuropäische Sommerzeit" value. You only need to fix the charset/truncation issue and that's all.
Regards, Sergei
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
From: maria-developers-bounces+wlad=montyprogram.com@lists.launchpad.net [mailto:maria-developers-bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Peter Laursen Sent: Donnerstag, 14. Juni 2012 21:50 To: Sergei Golubchik Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] MDEV-339 lp:1001340 system_time_zone is wrong on Windows "not every client would be able to read variable without loosing information". Since this is a client problem why then a patch in the server? It seems completely wrong to me! Client is anything that talks MySQL protocol . Per protocol specification, client can specify its character set. The client character set is not guaranteed to include full Unicode repertoire, or to include anything beyond ASCII (strictly speaking, even ASCII repertoire is not guaranteed) Am I missing something? Can we have some examples of clients where this is a problem? Command line client on say Russian Windows, with server on say German Windows. Command line client sets encoding by default to I believe cp866 (http://en.wikipedia.org/wiki/Code_page_866 ). cp866 does not have “ä” and won’t be able to represent string “Westeuropäische Sommerzeit” without losing information. Peter Webyog On Thu, Jun 14, 2012 at 9:11 PM, Sergei Golubchik <serg@askmonty.org> wrote: Hi, Vladislav! On Jun 14, Vladislav Vaintroub wrote:
At file:///H:/bzr/5.5/ <file:///H:\bzr\5.5\>
revno: 3434 revision-id: wlad@montyprogram.com-20120614122958-bq20w9xbqjw032nk parent: wlad@montyprogram.com-20120613093751-tv67fxuh1qcxm0by fixes bug: https://launchpad.net/bugs/1001340 committer: Vladislav Vaintroub <wlad@montyprogram.com> branch nick: 5.5 timestamp: Thu 2012-06-14 14:29:58 +0200 message: MDEV-339, LP1001340 - system_time_zone is wrong on Windows
On localized Windows versions, Windows uses localized time zone names. Since characters in timezone name can be outside of ASCII range, thus not every client would be able to read variable without loosing information, and even server misinterprets the encoding (it does not try to interpret the encoding).
The fix is to use the UTC offset format "+/-hh:mm" for system_time_zone on Windows, compatible with time_zone values everywhere else. UTC offset format is however not used if TZ environment variable is defined - MySQL documents to handle TZ environment variable in OS-dependent way.
I am not sure I like this idea. UTC offset format specifies a *different* time zone. Not the system one. Timezone that surely produces different results for the historical dates. Original bug report says that system_time_zone value is not a valid MySQL (or POSIX) time zone name. But is it a problem? When time_zone is set to SYSTEM, MariaDB will use OS functions for date/time conversion, and not the data from timezone tables. So it will use the system time zone *exactly*, not UTC offset approximation. And it won't try to look up system_time_zone value in the timezone tables. So, I think, it's quite ok for system_time_zone to have "Westeuropäische Sommerzeit" value. You only need to fix the charset/truncation issue and that's all. Regards, Sergei _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
participants (3)
-
Peter Laursen -
Sergei Golubchik -
Vladislav Vaintroub