develooper Front page | perl.perl6.language.datetime | Postings from August 2000

Re: Time core object and localtime() again

Thread Previous | Thread Next
Chris Nandor
August 22, 2000 09:21
Re: Time core object and localtime() again
Message ID:
At 17:44 +0200 2000.08.22, Markus Peter wrote:
>--On 22.08.2000 11:18 Uhr -0400 Chris Nandor wrote:
>> If there's a good reason to remove localtime(), then fine.  But please say
>> something more than "web applications don't need it."
>Well, I did not really talk about removing it - I know about the backwards
>compatibility issues. I know my mail was rather easy to misinterpret ;-)

Yes, well you did say, "In my opinion there's no reason for localtime or
gmtime to be in the core at all."  I guess that doesn't necessarily mean it
should be removed in your opinion, but it sure seems like it.

>What I actually wanted to express is that it's fairly useless in many cases
>and should be accompanied with useful date/time support in the standard

Yes, we should.

>Currently, handling date/time requires finding and using several modules
>like Time::Object, Date::Manip and POSIX or Time::Zone for correct
>timezones. I'm no C programmer unfortunately, so I could write the
>necessary system interfaces for especially the timezone stuff,otherwise I'd
>write this myself. I once did a Time::Zoneinfo module which could read
>Linux's zoneinfo files but then figured out it'd be better to rely on the
>system functions for that - which most systems have, than to repeat that

But many systems have no such thing, so we cannot rely on it.

>> 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.
>Well - I'd actually prefer useful Time/Date manipulations on 80% of the
>systems to the current situation.

And what's wrong with 100 percent, which seems to me to be achievable if we
supply the information with whatever module handles the calculations?

>Also, falling back to system resources is
>probably better than re-doing everything.

No, not if it still breaks on a bunch systems.

>For those systems not having
>timezone information or complete timezone information those zones would not
>be available until somebody installs a zoneinfo package or whatever - where
>exactly is the problem there?

I am not sure what you mean.  The problem is that it doesn't work on those

Chris Nandor            
Open Source Development Network

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About