perl time function

Discussion in 'Perl Misc' started by lerameur, Oct 17, 2007.

  1. lerameur

    lerameur Guest

    Hello,

    I know there are lot of function in perl.
    Can somebody tell me which function does the following:
    I have the : year, month, day, hours I want to increment the hours
    everytime the script is run. once the hours reaches 23 to 24 (actually
    0), it will increment the days. My concerns are with leap years and
    months

    thanks
    k
     
    lerameur, Oct 17, 2007
    #1
    1. Advertising

  2. lerameur wrote:
    > Hello,
    >
    > I know there are lot of function in perl.
    > Can somebody tell me which function does the following:
    > I have the : year, month, day, hours I want to increment the hours
    > everytime the script is run. once the hours reaches 23 to 24 (actually
    > 0), it will increment the days. My concerns are with leap years and
    > months


    See Date::Calc (Add_Delta_YMDHMS).

    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html
     
    Josef Moellers, Oct 17, 2007
    #2
    1. Advertising

  3. lerameur

    lerameur Guest

    On Oct 17, 10:33 am, Josef Moellers <josef.moell...@fujitsu-
    siemens.com> wrote:
    > lerameur wrote:
    > > Hello,

    >
    > > I know there are lot of function in perl.
    > > Can somebody tell me which function does the following:
    > > I have the : year, month, day, hours I want to increment the hours
    > > everytime the script is run. once the hours reaches 23 to 24 (actually
    > > 0), it will increment the days. My concerns are with leap years and
    > > months

    >
    > See Date::Calc (Add_Delta_YMDHMS).
    >
    > --
    > These are my personal views and not those of Fujitsu Siemens Computers!
    > Josef Möllers (Pinguinpfleger bei FSC)
    > If failure had no penalty success would not be a prize (T. Pratchett)
    > Company Details:http://www.fujitsu-siemens.com/imprint.html


    I used the same localtime I used, but I added hours+1 so that it
    output to another time variable and use that time to do my
    calculation.
    thanks
     
    lerameur, Oct 17, 2007
    #3
  4. lerameur

    smallpond Guest

    On Oct 17, 9:33 am, lerameur <> wrote:
    > Hello,
    >
    > I know there are lot of function in perl.
    > Can somebody tell me which function does the following:
    > I have the : year, month, day, hours I want to increment the hours
    > everytime the script is run. once the hours reaches 23 to 24 (actually
    > 0), it will increment the days. My concerns are with leap years and
    > months
    >
    > thanks
    > k



    Better to keep the time in seconds and use localtime to extract
    year/month/day/hour. Then you can just keep adding 3600 each
    hour. This way you don't have to reinvent what is probably the
    most frequently reinvented wheel in application programming.

    my $mytime = 1192633277;
    use constant ONEHOUR => 3600;

    $mytime += ONEHOUR;
    @t = localtime($mytime);
    ($year, $month, $day, $hour) = @t[5,4,3,2];

    --S
     
    smallpond, Oct 17, 2007
    #4
  5. lerameur

    Ben Morrow Guest

    Quoth smallpond <>:
    > On Oct 17, 9:33 am, lerameur <> wrote:
    > >
    > > I know there are lot of function in perl.
    > > Can somebody tell me which function does the following:
    > > I have the : year, month, day, hours I want to increment the hours
    > > everytime the script is run. once the hours reaches 23 to 24 (actually
    > > 0), it will increment the days. My concerns are with leap years and
    > > months

    >
    > Better to keep the time in seconds and use localtime to extract
    > year/month/day/hour. Then you can just keep adding 3600 each
    > hour. This way you don't have to reinvent what is probably the
    > most frequently reinvented wheel in application programming.


    Hours (or, at any rate, 'calendar hours') are not necessarily 3600
    seconds long, because of leap seconds. When doing calendar calculations,
    it's best to use a module that does it right.

    Ben
     
    Ben Morrow, Oct 17, 2007
    #5
  6. lerameur

    smallpond Guest

    On Oct 17, 11:53 am, Ben Morrow <> wrote:
    > Quoth smallpond <>:
    >
    > > On Oct 17, 9:33 am, lerameur <> wrote:

    >
    > > > I know there are lot of function in perl.
    > > > Can somebody tell me which function does the following:
    > > > I have the : year, month, day, hours I want to increment the hours
    > > > everytime the script is run. once the hours reaches 23 to 24 (actually
    > > > 0), it will increment the days. My concerns are with leap years and
    > > > months

    >
    > > Better to keep the time in seconds and use localtime to extract
    > > year/month/day/hour. Then you can just keep adding 3600 each
    > > hour. This way you don't have to reinvent what is probably the
    > > most frequently reinvented wheel in application programming.

    >
    > Hours (or, at any rate, 'calendar hours') are not necessarily 3600
    > seconds long, because of leap seconds. When doing calendar calculations,
    > it's best to use a module that does it right.
    >
    > Ben



    True. You could be as much as 2 seconds off if the program had
    been running for the last 10 years. By the way, how would a
    module know when leap seconds have been added? Would it check
    with IERS? Which modules take leap seconds into account?
    --S
     
    smallpond, Oct 17, 2007
    #6
  7. lerameur

    Guest

    On Oct 17, 8:53 am, Ben Morrow <> wrote:
    >
    > Hours (or, at any rate, 'calendar hours') are not necessarily 3600
    > seconds long, because of leap seconds. When doing calendar calculations,
    > it's best to use a module that does it right.
    >
    > Ben
    >


    a) Who keeps track of these things so that the module works correct?
    Just curious.

    Let's say it is N seconds since 1-Jan-1970, 00:00:00 (or whatever the
    base date-time), stored in variable t1, to 11:59:20 PM on date D, at
    the end of which 2 leap seconds get added. Going by your post, it
    looks like localtime($t1+45) would return 00:00:03 on date D+1 after
    adjusting for 2 leap seconds. b) Is my deduction correct?

    How many times have extra seconds been added or deducted since January
    1970?
     
    , Oct 17, 2007
    #7
  8. lerameur wrote:
    > On Oct 17, 10:33 am, Josef Moellers <josef.moell...@fujitsu-
    > siemens.com> wrote:
    >
    >>lerameur wrote:
    >>
    >>>Hello,

    >>
    >>>I know there are lot of function in perl.
    >>>Can somebody tell me which function does the following:
    >>>I have the : year, month, day, hours I want to increment the hours
    >>>everytime the script is run. once the hours reaches 23 to 24 (actually
    >>>0), it will increment the days. My concerns are with leap years and
    >>>months

    >>
    >>See Date::Calc (Add_Delta_YMDHMS).

    [...]
    > I used the same localtime I used, but I added hours+1 so that it
    > output to another time variable and use that time to do my
    > calculation.


    This was my first solution as well (use POSIX::mktime to convert from
    DMYhms to seconds, then add the delta, and then use localtime to convert
    back to DMYhms), but as others have pointed out, this doesn't take into
    account leap seconds. If this is for a production system, you better
    take care of this, or you may be called out of bed early one newyear's day.

    --
    These are my personal views and not those of Fujitsu Siemens Computers!
    Josef Möllers (Pinguinpfleger bei FSC)
    If failure had no penalty success would not be a prize (T. Pratchett)
    Company Details: http://www.fujitsu-siemens.com/imprint.html
     
    Josef Moellers, Oct 18, 2007
    #8
  9. On 2007-10-17 15:53, Ben Morrow <> wrote:
    >
    > Quoth smallpond <>:
    >> On Oct 17, 9:33 am, lerameur <> wrote:
    >> >
    >> > I know there are lot of function in perl.
    >> > Can somebody tell me which function does the following:
    >> > I have the : year, month, day, hours I want to increment the hours
    >> > everytime the script is run. once the hours reaches 23 to 24 (actually
    >> > 0), it will increment the days. My concerns are with leap years and
    >> > months

    >>
    >> Better to keep the time in seconds and use localtime to extract
    >> year/month/day/hour. Then you can just keep adding 3600 each
    >> hour. This way you don't have to reinvent what is probably the
    >> most frequently reinvented wheel in application programming.

    >
    > Hours (or, at any rate, 'calendar hours') are not necessarily 3600
    > seconds long, because of leap seconds. When doing calendar calculations,
    > it's best to use a module that does it right.


    When doing calendar calculations which may possibly include future dates
    you cannot use leap seconds. Leap seconds are determined by observation
    every six months, so at this point of time it is impossible to know how
    many seconds the year 2008 will have.

    This is why POSIX timestamps don't use leap seconds. The POSIX timestamp
    1199145600 always refers to 2008-01-01 00:00:00 UTC and the POSIX
    timestamp 1230768000 always refers to 2009-01-01 00:00:00 UTC,
    regardless of the number of actual seconds between these dates.

    So, if you really need to know the number of seconds between two
    timestamps, you can't just subtract them. OTOH, you can just add 3600 to
    get to the next calendar hour, as smallpond suggested.

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
     
    Peter J. Holzer, Oct 27, 2007
    #9
  10. lerameur

    Ben Morrow Guest

    Quoth "Peter J. Holzer" <>:
    > On 2007-10-17 15:53, Ben Morrow <> wrote:
    > >
    > > Hours (or, at any rate, 'calendar hours') are not necessarily 3600
    > > seconds long, because of leap seconds. When doing calendar calculations,
    > > it's best to use a module that does it right.

    >
    > When doing calendar calculations which may possibly include future dates
    > you cannot use leap seconds. Leap seconds are determined by observation
    > every six months, so at this point of time it is impossible to know how
    > many seconds the year 2008 will have.
    >
    > This is why POSIX timestamps don't use leap seconds. The POSIX timestamp
    > 1199145600 always refers to 2008-01-01 00:00:00 UTC and the POSIX
    > timestamp 1230768000 always refers to 2009-01-01 00:00:00 UTC,
    > regardless of the number of actual seconds between these dates.
    >
    > So, if you really need to know the number of seconds between two
    > timestamps, you can't just subtract them. OTOH, you can just add 3600 to
    > get to the next calendar hour, as smallpond suggested.


    OK, now I'm fascinated... what happens when a leap second occurs?
    time(3) returns the same value for two seconds in a row? That sounds...
    confusing, although I suppose it's similar to what adjtime(2) does...

    [Spurious Perl connection: this is similar to the hobbit's system of
    treating leap days as not part of the year... :)]

    Ben
     
    Ben Morrow, Oct 27, 2007
    #10
  11. On 2007-10-27 11:48, Ben Morrow <> wrote:
    >
    > Quoth "Peter J. Holzer" <>:
    >> On 2007-10-17 15:53, Ben Morrow <> wrote:
    >> > Hours (or, at any rate, 'calendar hours') are not necessarily 3600
    >> > seconds long, because of leap seconds. When doing calendar calculations,
    >> > it's best to use a module that does it right.

    >>
    >> When doing calendar calculations which may possibly include future dates
    >> you cannot use leap seconds. Leap seconds are determined by observation
    >> every six months, so at this point of time it is impossible to know how
    >> many seconds the year 2008 will have.
    >>
    >> This is why POSIX timestamps don't use leap seconds. The POSIX timestamp
    >> 1199145600 always refers to 2008-01-01 00:00:00 UTC and the POSIX
    >> timestamp 1230768000 always refers to 2009-01-01 00:00:00 UTC,
    >> regardless of the number of actual seconds between these dates.

    >
    > OK, now I'm fascinated... what happens when a leap second occurs?
    > time(3) returns the same value for two seconds in a row? That sounds...
    > confusing, although I suppose it's similar to what adjtime(2) does...
    >
    > [Spurious Perl connection: this is similar to the hobbit's system of
    > treating leap days as not part of the year... :)]


    What does the hobbit's system have to do with Perl?

    Anyway, to answer the question, there are a number of ways of dealing
    with leap seconds and it depends on the system which one is used:

    1) Just ignore the problem. At some time after the leap second, the
    system's time synchronisation system (probably NTP) will notice that
    the clock is now one second fast (or slow) and adjust accordingly.
    Different systems in your network will probably notice this at
    different times and the PLL may overshoot, so for a few hours the
    clocks of the systems may differ by a second or more until they have
    all converged again. However, you have similar problems after a
    reboot and reboots probably occur more often than leap seconds.

    2) Step the clock backwards or forwards by 1 second. Stepping the clock
    backwards may cause problems for some programs which assume
    monotonically increasing time. But again, time steps often occur
    after a reboot, so that may be acceptable.

    3) Halt the clock instead of stepping backwards: For one second, all
    calls to gettimeofday either return the same value, or just increment
    the microsecond counter.

    I am not sure, but I think Linux uses the third method. Don't know about
    other systems.

    hp


    --
    _ | Peter J. Holzer | It took a genius to create [TeX],
    |_|_) | Sysadmin WSR | and it takes a genius to maintain it.
    | | | | That's not engineering, that's art.
    __/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
     
    Peter J. Holzer, Oct 27, 2007
    #11
  12. lerameur

    Peter Scott Guest

    On Sat, 27 Oct 2007 17:00:42 +0200, Peter J. Holzer wrote:
    > On 2007-10-27 11:48, Ben Morrow <> wrote:
    >> [Spurious Perl connection: this is similar to the hobbit's system of
    >> treating leap days as not part of the year... :)]

    >
    > What does the hobbit's system have to do with Perl?


    Take a look at the comments at the beginnings of .c files in the Perl
    source distribution.

    --
    Peter Scott
    http://www.perlmedic.com/
    http://www.perldebugged.com/
     
    Peter Scott, Oct 28, 2007
    #12
  13. On 2007-10-28 09:03, Peter Scott <> wrote:
    > On Sat, 27 Oct 2007 17:00:42 +0200, Peter J. Holzer wrote:
    >> On 2007-10-27 11:48, Ben Morrow <> wrote:
    >>> [Spurious Perl connection: this is similar to the hobbit's system of
    >>> treating leap days as not part of the year... :)]

    >>
    >> What does the hobbit's system have to do with Perl?

    >
    > Take a look at the comments at the beginnings of .c files in the Perl
    > source distribution.


    Ah, I get it now. Thanks.

    hp


    --
    _ | Peter J. Holzer | It took a genius to create [TeX],
    |_|_) | Sysadmin WSR | and it takes a genius to maintain it.
    | | | | That's not engineering, that's art.
    __/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
     
    Peter J. Holzer, Oct 28, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. engsol
    Replies:
    2
    Views:
    959
    Dan Bishop
    Jan 26, 2004
  2. Replies:
    8
    Views:
    482
    Magnus Lycka
    Aug 5, 2005
  3. Peter Hansen
    Replies:
    0
    Views:
    720
    Peter Hansen
    Feb 22, 2006
  4. Peter Hansen
    Replies:
    0
    Views:
    612
    Peter Hansen
    Feb 22, 2006
  5. flamesrock
    Replies:
    8
    Views:
    484
    Hendrik van Rooyen
    Nov 24, 2006
Loading...

Share This Page