![[personal profile]](http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
fallenpegasusI just installed the Sun JRE RPM. I can't help but notice that it installed into /usr/java/jre*/lib/zi/ a nearly complete timezone database in it's own java-ish format.
All modern UNIX machines already have a completely complete timezone database, called the Olson Zoneinfo database, usually kept in /usr/share/zoneinfo/. It's kept exactingly complete and correct by an experienced and committed volunteer effort. The file format is tight, compact, and very easy to parse.
There is no excuse for Sun to clutter up my filesystem with a stale duplicate, and I'm willing to bet that their zi database is derived from an older version of the zoneinfo db.
They don't even need to change their API or any existing programs. I presume they were smart enough that the tz data is accessed thru some sort of abstract class interface. Just have that interface read and parse the zoneinfo db as needed, instead of their own db.
This rant was primed by my noticing that there is a CPAN Perl module that commits the same sin. DateTime::TimeZone contains a predigested and Perl-ized stale copy of the Olson database.
There is no reason for this! DateTime::TimeZone should access and parse the Zoneinfo db on demand, as it's used. There is no reason to waste space on millions of machines, in every CPAN replica, and on the bandwidth between CPAN and usermachines storing and hauling that data around, when it's already locally present.
Do Python and Ruby commit this same sin?
All modern UNIX machines already have a completely complete timezone database, called the Olson Zoneinfo database, usually kept in /usr/share/zoneinfo/. It's kept exactingly complete and correct by an experienced and committed volunteer effort. The file format is tight, compact, and very easy to parse.
There is no excuse for Sun to clutter up my filesystem with a stale duplicate, and I'm willing to bet that their zi database is derived from an older version of the zoneinfo db.
They don't even need to change their API or any existing programs. I presume they were smart enough that the tz data is accessed thru some sort of abstract class interface. Just have that interface read and parse the zoneinfo db as needed, instead of their own db.
This rant was primed by my noticing that there is a CPAN Perl module that commits the same sin. DateTime::TimeZone contains a predigested and Perl-ized stale copy of the Olson database.
There is no reason for this! DateTime::TimeZone should access and parse the Zoneinfo db on demand, as it's used. There is no reason to waste space on millions of machines, in every CPAN replica, and on the bandwidth between CPAN and usermachines storing and hauling that data around, when it's already locally present.
Do Python and Ruby commit this same sin?
![[identity profile]](http://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-10-23 06:55 pm (UTC)no subject
Date: 2007-10-23 08:24 pm (UTC)But even then, the smart thing is to pull in the zoneinfo db in it's native format.
And lobby Microsoft to use it...
no subject
Date: 2007-10-23 08:30 pm (UTC)no subject
Date: 2007-10-23 07:09 pm (UTC)no subject
Date: 2007-10-23 07:38 pm (UTC)no subject
Date: 2007-10-23 07:41 pm (UTC)At least they appear to have gotten that right in one.
no subject
Date: 2007-10-23 07:43 pm (UTC)http://tzinfo.rubyforge.org/
"TZInfo is a Ruby library that uses the standard tz (Olson) database to provide daylight savings aware transformations between times in different time zones. The tz database is compiled into Ruby modules which are packaged in the release. No external zoneinfo files are required at runtime."
*Sigh*