At 6:43 +0200 2000.08.22, Markus Peter wrote:
>In my opinion there's no reason for localtime or gmtime to be in the
>core at all.
I can think of two outstanding reasons for them to be in the core: because
they've already been there, and there is no reason to take it out.
>I especially want to focus on web applications with this
>proposal where the notion of a localtime becomes a bit superflous...
So core perl should leave something out if it is not useful to web
applications? That seems to be what you are saying, but I dearly hope I am
misinterpreting you.
>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
There's no reason you can't have this in addition to localtime and gmtime.
I do want to make one thing clear: I personally think it is unacceptable to
have any basic perl functionality, except for perhaps filehandles,
implemented only through objects. There is no need for it, and people
don't want it. People shouldn't have to learn about constructors and
references just to get the current time.
We shouldn't attempt to lose the original purpose and feel of Perl. In
fact, we should strive to keep them intact.
>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.
Systems have an installed database of time zones? Certainly not all of
them do. Relying on the system won't solve the problem, it will just make
it worse. We want time and date stuff to become MORE reliable across ALL
systems, not less reliable.
>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.
Almost everything you want to do, and perhaps all of it, is available now
with various Perl modules, like Date::Manip. That's all well and good.
Let's have good modules. But let's not relegate basic functionality many
of use a lot to a module just because we can. I like localtime(), I use it
all the time, and I am not keen on giving it up any time soon.
Again, let me repeat myself: let us not make objects required, and let us
not take things out or change things which don't need to be taken out.
If there's a good reason to remove localtime(), then fine. But please say
something more than "web applications don't need it."
--
Chris Nandor [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
