omponent:
sub format_time
{
my ( $self, $dt ) = @_;
return $dt->hms(':');
}
I'm hesitant to add additional logic here to handle the 1 second out
of a whole bunch of seconds where leap seconds come into play and
MySQL expects this value to be an extra long :59 but I'm happy to
prop
Dave Rolsky wrote:
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today
Thank you very much for this timely word of warning, Dave.
Barely 20 minutes after you posted your warning, I broadcasted it to the
developers at my workplace, and our
Can we lose leap seconds now?
The existence of time zones, DST, etc demonstrates that few outside of
niche astronomers care about matching local time with the sun to any
precision under about an hour or so. Running the posibility of bugs
is not worth it.
Ah, but you say that over time
Zefram wrote:
Jim Monty wrote:
Please explain this. I've always thought DateTime *does* handle leap
seconds correctly.
DateTime `knows', falsely, that there will be no more leap seconds
after
the last one that it knows of. You can see this, for example, by
asking
what is the UTC time N seconds
Monty, James T wrote:
Uh-oh, I don't get the same results with DateTime 0.4304 and ActivePerl
5.8.8 on Windows XP:
In the changelog:
|0.162003-08-06
|
|[ IMPROVEMENTS ]
|
|- The XS code now implements leap second-related calculations.
| However, this is only used on platforms where we can
Zefram wrote:
Jim Monty wrote:
Uh-oh, I don't get the same results with DateTime 0.4304 and
ActivePerl
5.8.8 on Windows XP:
In the changelog:
|0.162003-08-06
|
|[ IMPROVEMENTS ]
|
|- The XS code now implements leap second-related calculations.
| However, this is only used on platforms where
Monty, James T wrote:
Please explain this. I've always thought DateTime *does* handle leap
seconds correctly.
DateTime `knows', falsely, that there will be no more leap seconds after
the last one that it knows of. You can see this, for example, by asking
what is the UTC time N seconds after
in (second then days, or the reverse?).
In the case of UTC and leap seconds, most people probably don't care or
_need_ to care, so DateTime works just fine. For those folks who need to
care, they probably know what to look for, and can use Time::UTC.
This is different from date math, where most
Dave Rolsky wrote:
If I had it to do all over again, I might consider just ignoring leap
seconds altogether. It'd certainly make the internals much simpler. Then
for people who actually care, there would be a separate module that
handled leap seconds (and maybe _not_ time zones).
I guess
Why does time() return a multiple of 60? Surely each time there's a leap
second time()%60 should increment?
Cheers!
Rick Measham
Cause time since the epoch doesn't measure leap seconds. See in the
DateTime manual, under the epoch() method description.
On 11/20/05, Rick Measham [EMAIL PROTECTED] wrote:
Why does time() return a multiple of 60? Surely each time there's a leap
second time()%60 should increment?
Cheers
mathieu longtin wrote:
Cause time since the epoch doesn't measure leap seconds. See in the
DateTime manual, under the epoch() method description.
I'm aware that it doesn't measure them ... but I'm wondering why? Surely
that makes it Capital-W-Wrong. Perl will return the Wrong number
On Mon, 21 Nov 2005, Rick Measham wrote:
mathieu longtin wrote:
Cause time since the epoch doesn't measure leap seconds. See in the
DateTime manual, under the epoch() method description.
I'm aware that it doesn't measure them ... but I'm wondering why? Surely that
makes it Capital-W-Wrong
From the DateTime documentation, I would have thought that leap seconds apply
to all time zones (except floating ones), but the following code
use DateTime;
for my $time_zone (qw(UTC America/Los_Angeles)) {
my $now = DateTime-new(
year = 1972,
month
On Sat, 5 Nov 2005, Mike Schilli wrote:
From the DateTime documentation, I would have thought that leap seconds
apply
to all time zones (except floating ones), but the following code
use DateTime;
for my $time_zone (qw(UTC America/Los_Angeles)) {
my $now = DateTime-new
On Sun, 31 Jul 2005, Eugene van der Pijll wrote:
Dave Rolsky schreef:
http://www.post-gazette.com/pg/05210/545823.stm
Unfortunately it wouldn't make DT.pm any simpler, since we'd still have
the existing leap seconds to account for.
And we'd have to implement leap hours in UTC... (Though
http://www.post-gazette.com/pg/05210/545823.stm
Unfortunately it wouldn't make DT.pm any simpler, since we'd still have
the existing leap seconds to account for.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide
Dave Rolsky schreef:
http://www.post-gazette.com/pg/05210/545823.stm
Unfortunately it wouldn't make DT.pm any simpler, since we'd still have
the existing leap seconds to account for.
And we'd have to implement leap hours in UTC... (Though not for a couple
of hundred years, so you might just
On Fri, 6 Aug 2004, Eugene van der Pijll wrote:
I've attached a patch for the test files. I haven't looked into the
DateTime.pm code, because both leap second and the time zone handling
code are just too scary!
I checked this patch in. I'll try to fix this soon.
-dave
There's a bug somewhere in the interaction between leap seconds and time
zones.
In timezones with a positive offset, datetimes after local midnight but
before UTC midnight already are affected by the leap second:
$dt = DateTime-new( year = 1997, month = 7, day = 1
On Mon, 9 Feb 2004, Andrew Pimlott wrote:
Miscalculation of when we're in a leap minute.
Applied.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Miscalculation of when we're in a leap minute.
Andrew
--- lib/DateTime.pm.orig2004-01-07 17:39:02.0 -0500
+++ lib/DateTime.pm 2004-02-09 22:19:24.0 -0500
@@ -908,7 +908,7 @@
{
my ( $utc_rd_days, $utc_rd_secs ) = $smaller-utc_rd_values;
-if (
the generated code to use the binary
search method that Flavio's DateTime::LeapSecond generated code uses.
Ok, I did some benchmarks and it looks like date math involving leap
seconds (basically an DateTime object where the time zone is _not_
floating) has sped up about 10% or so, which is definitely a good
Dave Rolsky wrote:
Ok, I did some benchmarks and it looks like date math involving leap
seconds (basically an DateTime object where the time zone is _not_
floating) has sped up about 10% or so, which is definitely a good thing.
How about moving the pure-Perl DT::LeapSecond to DateTime.pm
How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ?
Seems like a good idea. Do you want to do it or should I?
I'd like to keep it separated. I believe it maybe useful outside the context of DT.
-J
--
Dave Rolsky wrote:
On Wed, 6 Aug 2003, Flavio S. Glock wrote:
Dave Rolsky wrote:
Ok, I did some benchmarks and it looks like date math involving leap
seconds (basically an DateTime object where the time zone is _not_
floating) has sped up about 10% or so, which is definitely
I suspect updates to it will be quite infrequent, though. Other than new
leap seconds, why else would it change?
I hadn't read ahead in my email. I was concerned about the functionality being
folding into the DT namespace and the DT::Leapsecond interface disappearing. That
didn't happen so
infrequent, though. Other than new
leap seconds, why else would it change?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Wed, 6 Aug 2003, Flavio S. Glock wrote:
Dave Rolsky wrote:
Ok, I did some benchmarks and it looks like date math involving leap
seconds (basically an DateTime object where the time zone is _not_
floating) has sped up about 10% or so, which is definitely a good thing.
How about
.
But when you upgraded DT::LeapSecond it would not recompile DateTime.
That's bad.
Yeah, that would be bad. The main reason I hadn't integrated this earlier
was that for some reason, I thought leap seconds were announced with very
little warning (1-2 days), but I found out that they're
It would be easy to change the Perl code generator
into a C code generator. Then you could use
DT::LeapSecond at compile time, if they are using
XS, or at runtime, if they are using pure Perl.
- Flavio S. Glock
On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
It would be easy to change the Perl code generator into a C code
generator. Then you could use DT::LeapSecond at compile time, if they
are using XS, or at runtime, if they are using pure Perl.
But the point is to avoid having to cross the Perl-C
The idea is: you call DT::LS from _DateTime_
Makefile.PL, and it generates C source code
that compiles with DT XS - it makes a C
include file - it is not a DT::LS XS library.
Dave Rolsky wrote:
On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
It would be easy to change the
On Saturday, July 12, 2003, at 01:06 AM, Dave Rolsky wrote:
I was thinking of doing this because leap seconds, even if they're not
abolished, are infrequent, and announced with enough lead time (6
months)
that making a new DateTime.pm release for them is not a problem.
The obvious benefit
May I import Date::Leapsecond into
modules/DateTime.pm/lib/DateTime/Leapsecond.pm?
I could then make the changes in DateTime to use it.
- Flavio S. Glock
On Sat, 12 Apr 2003 [EMAIL PROTECTED] wrote:
May I import Date::Leapsecond into
modules/DateTime.pm/lib/DateTime/Leapsecond.pm?
I could then make the changes in DateTime to use it.
How will it be used? I've been trying to think of a good way to handle
leapseconds in DateTime.pm for a while
Rich Bowen wrote:
leap seconds seem kinda arbitrary. Is that just a table that you look up
in?
Basically, yes.
Just like leap years, but there is no rule (there is no exact
calculations
for it).
Some (rarely) days will have one 0-60 seconds minute (instead of 0-59).
See also: Date::Leapsecond
We need to handle them. Flavio claims that using floating point seconds
makes this easier.
I have an idea on how to handle it without that, but I'd like to hear
Flavio's idea. And if anyone else has any good ideas or pointers to known
implementations (I know libtai64 handles it, for one),
38 matches
Mail list logo
