Re: [Maria-developers] [Commits] 9bb9bde: MDEV-6236 - [PATCH] mysql_tzinfo_to_sql may produce invalid SQL
Hi, Sergey! On Jun 03, svoj@mariadb.org wrote:
revision-id: 9bb9bde42dbf6f936faadeaa34cde838bf6b63dd parent(s): 54977bee6705b9f3ebe2e534245defdb18ac31be committer: Sergey Vojtovich branch nick: mariadb timestamp: 2015-06-03 14:30:09 +0400 message:
MDEV-6236 - [PATCH] mysql_tzinfo_to_sql may produce invalid SQL
Factory timezone is supposed "For companies who don't want to put time zone specification in their installation procedures. When users run date, they'll get the message. Also useful for the "comp.sources" version."
This "message" is exposed as timezone abbreviation, which is supposed to be short and thus may cause generated INSERT statements to fail.
Do not attempt to load Factory timezone.
Are you usure Factory is the only one with a message instead of a abbreviation? Perhaps it'd be safer to filter out all timezones with extra-long "abbreviations"? Regards, Sergei
Hi Sergei, speaking of IANA time zone database, there seem to be no other long abbreviations: for i in `find /usr/share/zoneinfo -type f` ; do zdump $i; done|sed "s/.*2015 //"|while read line; do echo ${#line} $line; done|sort -n But as we can see TZif permits abbreviations longer than 8 characters (while MariaDB/MySQL doesn't). In theory if we just filter out such time zones, we may miss very valid ones added in future (e.g. there're references to Mars time which they hope will be added some day). Also it is worth to note that there seem to be no other indication of what is actually stored in abbreviation. I compared Factory and UTC and the only difference was length of abbreviation and abbreviation text itself. There're many solutions to this problem (in my preference order): - filter out Factory time zone (1-st because simple) - increase Abbreviation size in time_zone_transition_type (2-nd because this is incompatible change) - filter out time zones with long abbreviations (suggested in MDEV-6236) - filter out time zones with abbreviation == "Local time zone must be set..." (the MySQL way of fixing things) :) So I'd prefer to error out and fix every individual occurence instead of silently ignoring them. Please confirm you still don't like this proposed solution. Thanks, Sergey On Wed, Jun 03, 2015 at 03:58:55PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
On Jun 03, svoj@mariadb.org wrote:
revision-id: 9bb9bde42dbf6f936faadeaa34cde838bf6b63dd parent(s): 54977bee6705b9f3ebe2e534245defdb18ac31be committer: Sergey Vojtovich branch nick: mariadb timestamp: 2015-06-03 14:30:09 +0400 message:
MDEV-6236 - [PATCH] mysql_tzinfo_to_sql may produce invalid SQL
Factory timezone is supposed "For companies who don't want to put time zone specification in their installation procedures. When users run date, they'll get the message. Also useful for the "comp.sources" version."
This "message" is exposed as timezone abbreviation, which is supposed to be short and thus may cause generated INSERT statements to fail.
Do not attempt to load Factory timezone.
Are you usure Factory is the only one with a message instead of a abbreviation?
Perhaps it'd be safer to filter out all timezones with extra-long "abbreviations"?
Regards, Sergei
Hi, Sergey! On Jun 03, Sergey Vojtovich wrote:
Hi Sergei,
speaking of IANA time zone database, there seem to be no other long abbreviations:
But as we can see TZ if permits abbreviations longer than 8 characters (while MariaDB/MySQL doesn't). In theory if we just filter out such time zones, we may miss very valid ones added in future (e.g. there're references to Mars time which they hope will be added some day).
There're many solutions to this problem (in my preference order): - filter out Factory time zone (1-st because simple) - increase Abbreviation size in time_zone_transition_type (2-nd because this is incompatible change) - filter out time zones with long abbreviations (suggested in MDEV-6236) - filter out time zones with abbreviation == "Local time zone must be set..." (the MySQL way of fixing things) :)
So I'd prefer to error out and fix every individual occurence instead of silently ignoring them. Please confirm you still don't like this proposed solution.
I don't like the 2nd and 3rd solutions (2nd - incompatible for no good reason, 3rd - I want to know when a timezone with long abbreviation appears, there must be a warning, it shouldn't be silently ignored). The 4th approach seems preferrable, assuming that one can create another timezone for himself (or the organization) that would also have "Local time zone must be set...", But if nobody's doing that (which, I believe, is very close to the truth :), we can stay with your simple fix. Regards, Sergei
participants (2)
-
Sergei Golubchik -
Sergey Vojtovich