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), please
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
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
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 w
I just checked this in, but I'm not sure if it's much faster. It'd be
good if someone who knows more about about C could look at the
implementation and see if there's anything they can think of to improve
it. Also, I should probably change the generated code to use the binary
search method that F
Why does time() return a multiple of 60? Surely each time there's a leap
second time()%60 should increment?
Cheers!
Rick Measham
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
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 they will
Ben Tilly wrote:
>Can we lose leap seconds now?
That's being discussed over at . You should
peruse the list archives, where all the points you raise have been
discussed extensively.
>From a DateTime point of view, the merits of leap seconds are irrelevant.
Our job is to handle
T.
I suspect updates to it will be quite 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 defin
> 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
di
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_
> >
so, I should probably change 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 u
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
> > 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
--
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
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
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
make
Rick Measham wrote:
> 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 of
> elapsed seconds since 1970 ...
That depends on what kind of seconds you are counting.
It is right if you are counting mean solar s
hat order the
math is done 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 d
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
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,
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 pl
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 =&g
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
You
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 =>
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 benef
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 Sun, Jul 13, 2003 at 07:44:10PM -0500, Dave Rolsky wrote:
> 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
> > 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 when you upgraded DT::LeapSecon
> are using XS, or at runtime, if they are using pure Perl.
> >
>
> 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 secon
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 ( $u
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
/*
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
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
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->
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
===*/
checking for
leap_seconds when constructing the time component:
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
43 matches
Mail list logo
