LWN.net Logo

Java doesn't use zoneinfo

Java doesn't use zoneinfo

Posted Mar 8, 2007 2:48 UTC (Thu) by bcd (subscriber, #11759)
In reply to: Dimdows by ldo
Parent article: Switching your Linux systems to the new DST (Linux-Watch)

Not quite true... Java does not use zoneinfo, it uses its own internal database instead. See http://java.sun.com/developer/technicalArticles/Intl/USDST/ for more information. They are providing a tool to patch existing installations if a full upgrade isn't possible.


(Log in to post comments)

Java doesn't use zoneinfo

Posted Mar 8, 2007 15:22 UTC (Thu) by nix (subscriber, #2304) [Link]

PostgreSQL, Python and Perl also have their own private copies of the Olson database.

not using zoneinfo

Posted Mar 8, 2007 23:50 UTC (Thu) by ldo (subscriber, #40946) [Link]

Don't you think that's stupid? What's the excuse of these people for not using zoneinfo and the standard C run-time API calls for accessing it?

For instance, I look at Perl and Python, and I can see no timezone functionality that they offer beyond what's available through the standard C run-time.

not using zoneinfo

Posted Mar 10, 2007 1:36 UTC (Sat) by nix (subscriber, #2304) [Link]

They do use the standard C runtime API calls: but if you want to ask what
the time is in something other than the current locale, or if you want to
make any query of the timezone database other than `what time is it now'
(perhaps `when does the time change next' or `will the time jump in the
next day') then POSIX provides no interfaces that will help (and neither
does glibc, nor will it ever, apparently).

So in that situation you must either locate and directly access the system
timezone database, or ship your own and suitable query code. (PostgreSQL
does the latter so that it can implement timestamps, WITH TIME ZONE types,
and so forth.)

not using zoneinfo

Posted Mar 11, 2007 1:36 UTC (Sun) by ldo (subscriber, #40946) [Link]

All the things you mentioned can be determined from the standard zoneinfo database. I could probably even calculate them all just by using the standard POSIX API calls.

Repeat after me: "Always use zoneinfo! Never try to roll-your-own!"

Blame POSIX

Posted Mar 11, 2007 10:53 UTC (Sun) by kleptog (subscriber, #1183) [Link]

PostgreSQL does use the zoneinfo database, they just modified the code to make it more usable. Until recently the zoneinfo database was 100% compatable so you could symlink them with the version supplied by the OS. (Upstream added support for leap-seconds, which changed the disk format). The reasons why PostgreSQL uses its own are:

1. Access to multiple timezones. The only way to do that in POSIX is to set the TZ environment variable. Which means that if you run a query using two timezones, the C library would reload the timezone file twice for every row in your query. Say goodbye to performance.

2. Cross-platform support. Not every OS uses zoneinfo (*cough*Windows*cough*), so if you want consistant query results across 11 OSes, you need to manage it yourself.

3. Stability. Not every C library was memory-leak free when faced with hundreds of timezone changes per second.

If the writers of POSIX had simply from the beginning decided to allow the timezone as an argument to the time functions, this would be much less of an issue. Recently I looked at glib, figuring it might handle this. But no, it also assumes your whole program only wants to work in one timezone. Ugh.

I made a plugin to Gaim to display the times of other users. I also copied the zoneinfo code into that, because it's a big no-no for plugins to start playing with environment variables, especialy those with such a wide effect as TZ... Yes, Glibc can do it, but there's always the *but it doesn't work on Windows* crew...

not using zoneinfo

Posted Mar 9, 2007 2:35 UTC (Fri) by ldo (subscriber, #40946) [Link]

Somehow I didn't think the people behind Python and Perl were that stupid, so I went back to check.

On a SuSE 9.3 system I just updated a few days ago with the latest timezone RPM, both Python and Perl do correctly show local times across the upcoming daylight-saving transition in the US time zones.

Checking the contents of that RPM, it contains a few updated utility binaries, plus of course a new version of the zoneinfo database. No Python- or Perl-specific (or other language-specific) updates at all.

not using zoneinfo

Posted Mar 10, 2007 1:31 UTC (Sat) by nix (subscriber, #2304) [Link]

Python, oops, I misspoke (no Python sources nearby when I posted that and
I was going from fallible memory).

As for Perl, the DateTime::TimeZone module on CPAN incorporates a copy of
the Olson database.

Re: Java doesn't use zoneinfo

Posted Mar 9, 2007 2:38 UTC (Fri) by ldo (subscriber, #40946) [Link]

I find that a shock, given that Sun hold one of the major concentrations of Unix mojo going back decades. Why on Earth would they do things in such a brain-damaged way?

Re: Java doesn't use zoneinfo

Posted Mar 9, 2007 6:52 UTC (Fri) by njs (subscriber, #40338) [Link]

For the same reason that Java specifies the exact size of its integer types (unlike C) and makes it a fatal compiler error to have an potentially uninitialized variable -- the goal was to make the behavior predictable in *every* case, no matter the underlying hardware, OS, etc.

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds