Bug 466383 - mysql_tzinfo_to_sql will not process RiyadhXX time zones
Summary: mysql_tzinfo_to_sql will not process RiyadhXX time zones
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql
Version: 5.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-09 23:25 UTC by Bryan Mason
Modified: 2018-10-20 02:58 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-31 00:25:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bryan Mason 2008-10-09 23:25:31 UTC
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

Comment 1 Bryan Mason 2008-10-09 23:38:37 UTC
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.

Comment 8 RHEL Program Management 2009-03-31 00:25:09 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.


Note You need to log in before you can comment on or make changes to this bug.