Front page | perl.perl6.language.datetime |
Postings from August 2000
Hello
This is a follow up to various discussions about localtime() and time
objects on the other lists. I hope this is not out of scope as all this
could be done already with Perl 5 and a module (though I think it really
belongs into the distribution)
In my opinion there's no reason for localtime or gmtime to be in the
core at all. I especially want to focus on web applications with this
proposal where the notion of a localtime becomes a bit superflous...
A future standard time object should contain all the features of the
current Time::Object. In addition, it should ease the use of different
time zones. Currently, this involves fiddling with $ENV{TZ} and POSIX.pm
which might look like:
$ENV{TZ}='GMT';
my $time= POSIX::mktime($sec,$min,$hour....);
$ENV{TZ}=$target_timezone;
my @time= localtime($time);
This is ugly...
Instead of gmtime, localtime etc. we might want to handle this via the
constructor of the time object:
my $t= new Time($time); # for $ENV{TZ}/system dependant localtime
my $t= new Time($time,'GMT'); # gmtime replacement
my $t= new Time($time,'CET'); # chooses CET/CEST
Needless to say, the time zone data should come from the system installed
database of timezones, unlike e.g. the current Time::Zone module which is
basically not usable because of inaccuracies and some other shortcomings
(e.g. no automatic daylight saving time adjustments) as it uses its own
data.
The base time object should also contain equivalents to POSIX::mktime and
POSIX::strftime - that module is simply too large if I only need time
operations and it's nice to have everything in one place.
Another interesting way to construct a Time object would be from a string
scalar looking like an SQL date: 'YYYYMMDDhhmmss' as this is a rather
common case, too.
--
Markus Peter - SPiN GmbH
warp@spin.de
Thread Next