John Tobey <[EMAIL PROTECTED]> writes:
> On Tue, Aug 08, 2000 at 10:47:10PM -0700, Russ Allbery wrote:
>> It's far worse than non-portable; it's completely insufficient. The
>> POSIX TZ syntax cannot represent many real time zones. You need the
>> Olson-style naming scheme which refers to entries in a fairly large
>> external database
> You mean the "EST5EDT", "US/Pacific", "America/New_York", and suchlike
> files in /usr/share/zoneinfo.
Specifically America/New_York, yes. The other two names you list are from
inferior naming schemes that ideally should go away; they're basically
just aliases for the more accurate names and have been for a while.
Okay, I guess the question is whether the goal is to provide access to the
real time zones or to the system time zone library. If the latter,
that's simpler, but a lot of systems don't have adequate time zone support
to do what you really want. Particularly non-Unix systems; pretty much
all Unix systems at this point use *some* version of the Olson library,
although their data may be woefully out of date.
> Actually, I do use those indirectly, though probably non-portably, by
> localizing C<$ENV{TZ}>. GNU Libc takes care of finding the zoneinfo
> file, but lamentably reparses it every time TZ changes and
> C<POSIX::tzset> is called.
That's fine; zoneinfo files are designed for that. They're extremely fast
to parse. That's what you want.
I'm not as worried about Unix, since most Unixes have a decent time zone
library. I'm worried more about all the *other* platforms that Perl
supports; if we want time zone support to be portable, I'm pretty sure
we'd end up embedding the tz library, since otherwise the results are
going to vary wildly in quality from system to system. (Even worse than
the situation with sprintf.)
I think this is a bit heavy-weight for core.
> My module does not parse old-style TZ formats,
Nothing should really ever use them anyway, so I wouldn't be too worried
about that.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
