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
>distribution.
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
>work.
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
systems.
--
Chris Nandor [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/