?

Log in

No account? Create an account
entries friends calendar profile My Website Previous Previous Next Next
Rant. TZ data, and annoying behavior by Java and Perl - Mark Atwood
fallenpegasus
fallenpegasus
Rant. TZ data, and annoying behavior by Java and Perl
I 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?

Tags: , , , , , ,
Current Location: Remedy Tea, Capitol Hill, Seattle WA
Current Mood: annoyed annoyed

7 comments or Leave a comment
Comments
hollyking From: hollyking Date: October 23rd, 2007 06:55 pm (UTC) (Link)
The only reason I can think of to include it is for systems, such as Windows, that don't have the Olson database.
fallenpegasus From: fallenpegasus Date: October 23rd, 2007 08:24 pm (UTC) (Link)
In such cases, they can pull it in, if they need it.

But even then, the smart thing is to pull in the zoneinfo db in it's native format.

And lobby Microsoft to use it...
hollyking From: hollyking Date: October 23rd, 2007 08:30 pm (UTC) (Link)
Agreed.
codetoad From: codetoad Date: October 23rd, 2007 07:09 pm (UTC) (Link)
Python's std libs have no timezone concept, but pytz does this.
ckn From: ckn Date: October 23rd, 2007 07:38 pm (UTC) (Link)
I agree that zi is likely flawed and not up to date. IIRC this past spring when we did the DST change there were some FAQ describing how to roll your own zi files because of this flaw. ...and it was something that we rapidly merged into our production systems due to zi being made of up of old zonefiles....
helix90 From: helix90 Date: October 23rd, 2007 07:41 pm (UTC) (Link)
According to http://tzinfo.rubyforge.org/ the Ruby library is just a call to the Olson database.

At least they appear to have gotten that right in one.
elfs From: elfs Date: October 23rd, 2007 07:43 pm (UTC) (Link)
Note the fine print:

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*
7 comments or Leave a comment