Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> The C<$time> specifier can be followed by a C<$timezone> argument, which
> returns the date relative to that timezone. By default, the time is
> returned relative to the local timezone. You can get UTC, for example,
> by specifying C<UTC> or C<GMT> as the timezone.
> # Access UTC information
> $scalar = date time, '%H:%M', 'UTC'; # return time in UTC
> $object = date time, undef, 'GMT'; # return object in UTC
> # Explicity get ctime date for Eastern US time
> # If $time is undef, time() is assumed
> $scalar = date undef, undef, 'EST';
Whatever you do, don't use those timezone names. Is EST Eastern US time
or Eastern Standard Time in Australia? The same abbreviation is used in
both places.
Naming of time zones is a *huge* rathole that you probably just don't want
to crawl into. The short abbreviations are *not* standardized and are
quite frequently ambiguous. There are three other prevelant time-zone
naming schemes: the POSIX one (EST5EDT, for example) is completely
insufficient to actually represent time zone variations as they occur in
the real world, the "old Olson" found in most Unix operating systems these
days with names like US/Pacific doesn't offer enough granularity, and the
"new Olson" method (the best of the lot) uses names that most people don't
know (America/Los_Angeles for US Pacific for example).
Basically, you don't want to go anywhere near this mess; it eats people.
I see two reasonable options to go with instead. One is to just use a
binary flag that says use UTC or not; this is the simplest and most
reliable to explain. The other is to allow a timezone offset; this
doesn't deal with daylight savings time and historic time zone changes,
but it provides enough power for most of what people want to do and if you
want to deal with the rest you have to deal with time zone naming.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
