On Wed, Aug 09, 2000 at 02:22:22AM +0200, Bart Lateur wrote:
> I have a server in the UK, while I'm in Belgium. Different time zones.
> So localtime() won't return the time in *my* localtime.
>
> So we have two almost identical functions in the core, gmtime and
> localtime, where one gives an offset of zero, and the other an offset
> based upon the time zone settings of your system. It's a very small
> difference. Those are the most commonly requested time representations,
> but as in my example, it's not enough.
>
> date() would be more general, and replace both. You can pass it a time
> zone, ANY time zone, and it will tell you what time it is in that time
> zone.
Multiple timezone support in a single process should definitely be
supported, *ideally*. I don't think this RFC is even proposing that.
It is very difficult to do right. I spent several months trying; you
can see my work using these CVS commands:
echo :pserver:[EMAIL PROTECTED]:/home/cvs A >> ~/.cvspass
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co Date
The JTobey::Date module uses the TZ environment variable (which, I'm
told, is non-portable), the esoteric POSIX routines tzset and tzname,
and some functions from the CPAN modules Date::Parse and Date::Format.
It is designed to give it all an easy OO interface, and to be as
correct as possible on systems like mine. It is not expected to be
very fast, portable, or locale-friendly.
To overcome these problems would be a Herculean task which I simply
doubt that anyone here is willing to do. Therefore, I oppose the
notion that Perl 6 will magically handle all this.
-John
