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 wrote:
> Hello,
>=20
> 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).
--=20
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
On Oct 17, 10:33 am, Josef Moellers
> 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. Pratc=
hett)
> 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
On Oct 17, 9:33 am, 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
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
Quoth smallpond
> On Oct 17, 9:33 am, lerameur
> >
> > 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 (ben@morrow.me.uk) wrote on VCLX September MCMXCIII in
--
-- Quoth smallpond
-- > On Oct 17, 9:33 am, lerameur
-- > >
-- > > 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.
Yeah, but if you have a system that using Unix time to do timestamps,
using a module that considers leapseconds will get you fucked, because
Unix doesn't know about leap seconds.
Considering leap seconds when doing data calculations is only useful
if your timestamps know about leap seconds in the first place. And
only if you need second precision in your answer.
Abigail
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(
HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (
LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET",
"http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl ")) -> content))
=~ /(.*\))[-\s]+Addition/s) [0]'
On Oct 17, 11:53 am, Ben Morrow
> Quoth smallpond
>
> > On Oct 17, 9:33 am, lerameur
>
> > > 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
On Oct 17, 8:53 am, Ben Morrow
>
> 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?
lerameur wrote:
> On Oct 17, 10:33 am, Josef Moellers
>=20
>>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=20
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=20
account leap seconds. If this is for a production system, you better=20
take care of this, or you may be called out of bed early one newyear's da=
y.
--=20
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
On 2007-10-17 15:53, Ben Morrow
>
> Quoth smallpond
>> On Oct 17, 9:33 am, lerameur
>> >
>> > 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.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Quoth "Peter J. Holzer"
> On 2007-10-17 15:53, Ben Morrow
> >
> > 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
On 2007-10-27 11:48, Ben Morrow
>
> Quoth "Peter J. Holzer"
>> On 2007-10-17 15:53, Ben Morrow
>> > 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.
| | | hjp@hjp.at | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
On Sat, 27 Oct 2007 17:00:42 +0200, Peter J. Holzer wrote:
> On 2007-10-27 11:48, Ben Morrow
>> [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/
On 2007-10-28 09:03, Peter Scott
> On Sat, 27 Oct 2007 17:00:42 +0200, Peter J. Holzer wrote:
>> On 2007-10-27 11:48, Ben Morrow
>>> [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.
| | | hjp@hjp.at | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex