From: maria-developers-bounces+wlad=montyprogram....@lists.launchpad.net 
[mailto:maria-developers-bounces+wlad=montyprogram....@lists.launchpad.net] On 
Behalf Of Peter Laursen
Sent: Donnerstag, 14. Juni 2012 21:50
To: Sergei Golubchik
Cc: [email protected]
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 <[email protected]> wrote:
Hi, Vladislav!

On Jun 14, Vladislav Vaintroub wrote:
> At file:///H:/bzr/5.5/ <file:///H:\bzr\5.5\> 
>
> revno: 3434
> revision-id: [email protected]
> parent: [email protected]
> fixes bug: https://launchpad.net/bugs/1001340
> committer: Vladislav Vaintroub <[email protected]>
> 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     : [email protected]
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp
 
_______________________________________________
Mailing list: https://launchpad.net/~maria-developers
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to