perl time function

[lerameur]

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

 

[Josef Moellers]

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

 

[lerameur]

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

 

[smallpond]

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

 

[Ben Morrow]

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

 

[smallpond]

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

 

[dn.perl]

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?

 

[Josef Moellers]

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.

 

[Peter J. Holzer]

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

 

[Ben Morrow]

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

 

[Peter J. Holzer]

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 Scott]

[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 J. Holzer]

[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