On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
But why would people do that on Solaris is my question.
For some reason it doesn't always identify that gcc is available (thats
how I noticed the problem). Don't ask me why someone would install the
XS version then switch to pure-perl. Never the
No, Dynloader's doing what it's supposed to, which is try to find an .so
for the module. The problem is that the one it finds is for the wrong
version.
No versioning information is written into the .so?
-J
--
For inclusion with DT::Locale.
Comments?
-J
--
package DateTime::Locale::Alias;
use strict;
use vars qw( $VERSION );
$VERSION = 0.01;
use DateTime::Locale;
sub import {
my $class = shift;
return unless @_;
DateTime::Locale-add_aliases( { @_ } );
}
1;
__END__
=pod
=head1
Ben Bennett schreef:
Use of uninitialized value in numeric ne (!=) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/DateTime.pm line
1174.
Use of uninitialized value in numeric comparison (=) at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/DateTime.pm line
1174.
Span cannot
I've encountered a bug in DT::Infinite math. It seems that adding a
number of days to DT::Infinite::Future results in a DT::I::Future object
again, but adding a number of years changes it.
For example:
my $dt = DateTime-now;
my $dt_inf = DateTime::Infinite::Future-new;
print
On Fri, 1 Aug 2003, Eugene van der Pijll wrote:
I've encountered a bug in DT::Infinite math. It seems that adding a
number of days to DT::Infinite::Future results in a DT::I::Future object
again, but adding a number of years changes it.
For example:
my $dt = DateTime-now;
my
0.1503 2003-07-31
[ BUG FIXES ]
- Adding a duration with delta months to an infinite DateTime was
quite broken. Reported by Eugene van der Pijll.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
At 9:42 AM +1000 1/8/03, Iain Truskett wrote:
Does anyone know of a machine-readable map that can convert lat/lon
to timezone?
Mac uses a map, you click on the map and it tells you the time at
that place in the world. Of course it's closed source so we can't get
a copy of it :(
I remember that
I think it would be useful to make a set of TZ aliases per
country... like the US/Eastern, etc. stuff but for every country.
It would be even more useful to be able to break it down further as
needed (state by state and county by county as needed). But that is a
lot of work.
I said:
The problem with converting lat/lon is that countries are not
geometric shapes where it would be easy to determine if a particular
lat/lon is within that country.
But now I've found the data! Problem is that each country is made up
of a group of polygons. Each point on the polygon is in
At 11:23 AM +1000 1/8/03, Iain Truskett wrote:
* Rick Measham ([EMAIL PROTECTED]) [01 Aug 2003 11:09]:
[...]
But now I've found the data! Problem is that each country is made up
of a group of polygons. Each point on the polygon is in lat/lon
format. However we can't really use this data. It's
Perhaps it is useful to specify a rule that DT::Format formatting
routines should never change the object they are passed. Before changing
anything, clone the object first. Is this something to add to the
development standards?
Thats a _very_ good idea.
[1] Why UTC? Wouldn't
12 matches
Mail list logo
