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/
>
> 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