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

Search Discussions

  • Chris Nandor at Aug 22, 2000 at 3:19 pm

    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 pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Markus Peter at Aug 22, 2000 at 3:44 pm

    --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 ;-)
    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.

    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.
    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. Also, falling back to system resources is
    probably better than re-doing everything. 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?
    --
    Markus Peter - SPiN GmbH
    warp@spin.de
  • Chris Nandor at Aug 22, 2000 at 4:21 pm

    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 pudge@pobox.com http://pudge.net/
    Open Source Development Network pudge@osdn.com http://osdn.com/
  • Markus Peter at Aug 22, 2000 at 4:31 pm

    --On 22.08.2000 12:18 Uhr -0400 Chris Nandor wrote:

    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.
    As I said - my mail was easy to misinterpret ;-) But enough of that.
    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.
    Great.
    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?
    Well - after all it's just an implementation detail... My question is what's
    wrong to only supply the information on perl ports where systems do not
    have zoneinfo ? But I've to admit that I don't really care as long as we
    finally have complete standard support for time/date operations.

    --
    Markus Peter - SPiN GmbH
    warp@spin.de
  • Jonathan Scott Duff at Aug 22, 2000 at 4:38 pm

    On Tue, Aug 22, 2000 at 06:31:14PM +0200, Markus Peter wrote:
    Well - after all it's just an implementation detail... My question is what's
    wrong to only supply the information on perl ports where systems do not
    have zoneinfo ? But I've to admit that I don't really care as long as we
    finally have complete standard support for time/date operations.
    Perhaps you missed this message:

    http://www.mail-archive.com/perl6-language-datetime%40perl.org/msg00003.html

    and the ensuing thread?

    -Scott
    --
    Jonathan Scott Duff
    duff@cbi.tamucc.edu

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language-datetime @
categoriesperl
postedAug 22, '00 at 4:43a
activeAug 22, '00 at 4:38p
posts6
users3
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase