Bug 466383
| Summary: | mysql_tzinfo_to_sql will not process RiyadhXX time zones | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Bryan Mason <nobody+bjmason> |
| Component: | mysql | Assignee: | Tom Lane <tgl> |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE <qe-baseos-auto> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.2 | CC: | bmason, byte, hhorak, patrickm, sghosh, syeghiay, tao |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-03-31 00:25:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The problem apparently occurs becuase the RiyadhXX time zones have too many types. The errors are generated when tz_load() (in sql/mysql_tzinfo_to_sql.cc) returns a non-zero value. tz_load() returns a non-zero value here:
193 if (sp->leapcnt > TZ_MAX_LEAPS ||
194 sp->typecnt == 0 || sp->typecnt > TZ_MAX_TYPES ||
195 sp->timecnt > TZ_MAX_TIMES ||
196 sp->charcnt > TZ_MAX_CHARS ||
197 (ttisstdcnt != sp->typecnt && ttisstdcnt != 0) ||
198 (ttisgmtcnt != sp->typecnt && ttisgmtcnt != 0))
199 return 1;
The problem is that sp->typecnt > TZ_MAX_TYPES.
TZ_MAX_TYPES is defined in sql/tzfile.h:
87 #ifndef TZ_MAX_TYPES
88 #ifdef SOLAR
89 #define TZ_MAX_TYPES 256 /* Limited by what (unsigned char)'s can hold */
90 #else
91 /*
92 Must be at least 14 for Europe/Riga as of Jan 12 1995,
93 as noted by Earl Chew <earl.hp.com>.
94 */
95 #define TZ_MAX_TYPES 20 /* Maximum number of local time types */
96 #endif /* defined SOLAR */
97 #endif /* !defined TZ_MAX_TYPES */
sql/tzfile.h also has this tidbit of information:
108 #ifndef TZ_MAX_REV_RANGES
109 #ifdef SOLAR
110 /* Solar (Asia/RiyadhXX) zones need significantly bigger TZ_MAX_REV_RANGES */
111 #define TZ_MAX_REV_RANGES (TZ_MAX_TIMES*2+TZ_MAX_LEAPS*2+2)
112 #else
113 #define TZ_MAX_REV_RANGES (TZ_MAX_TIMES+TZ_MAX_LEAPS+2)
114 #endif
115 #endif
which would imply that SOLAR should be #defined to handle the RiyadhXX time zone information. I've been able to verify that defining SOLAR avoids the error messages and appears to load the time_zone_transition_type table correctly.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |
Description of problem: Running "mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql" reports the following errors: Warning: Unable to load '/usr/share/zoneinfo/Asia/Riyadh87' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/Asia/Riyadh88' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/Asia/Riyadh89' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/Mideast/Riyadh87' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/Mideast/Riyadh88' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/Mideast/Riyadh89' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/posix/Asia/Riyadh87' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/posix/Asia/Riyadh88' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/posix/Asia/Riyadh89' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/posix/Mideast/Riyadh87' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/posix/Mideast/Riyadh88' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/posix/Mideast/Riyadh89' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/right/Asia/Riyadh87' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/right/Asia/Riyadh88' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/right/Asia/Riyadh89' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/right/Mideast/Riyadh87' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/right/Mideast/Riyadh88' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/right/Mideast/Riyadh89' as time zone. Skipping it. Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it. The warnings about ios3166.tab and zone.tab are valid and correct (those files are text files and not time zone files). Version-Release number of selected component (if applicable): mysql-server-5.0.45-7.el5.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Run "mysql_tzinfo_to_mysql /usr/share/zoneinfo" Actual results: Errors shown above. SQL commands to load the database with the Riyadh87, Riyadh88, and Riyadh89 time zones are not generated. Expected results: No errors. All timezones are processed. Additional info: A simpler test case is to copy /usr/share/zoneinfo/Asia/Riyadh87 to /tmp/zoneinfo/Riyadh87, run mysql_tzinfo_to_mysql /tmp/zoneinfo > /dev/null and check for errors. Apparently the timezone in Saudia Arabia followed solar time, so that sunset would occur at 00:00:00 local time, from 1987-1989. For more information, see: http://www.velocityreviews.com/forums/t543449-riyadh-timezone.html http://mindprod.com/jgloss/timezone.html