On Fri, 14 Nov 2003, Jonathan Swartz wrote:
I guess this boils down to four choices:
1) give an arbitrary answer
2) give a reasonable answer that may depend on the current time (add both
durations to the current time and compare the resulting times)
3) give an answer if it is correct for
On Thu, 13 Nov 2003, Joshua Hoblitt wrote:
Seriously, I'd like to eventually speed up/slim down the time zone stuff
but just getting it working took an enormous amount of development effort.
Making a super-fast whiz-bang version that still works is not trivial.
Maybe we should ask around
On Thu, 13 Nov 2003, Matt Sisk wrote:
Since the time zone classes are generated, it'd be possible to generate XS
code instead of Perl. Patches or a shipment of tuits would be extremely
welcome.
The timezone modules use lots of spans, correct?
No, it's just a big data structure (an array
On Thu, 13 Nov 2003, Matt Sisk wrote:
Matt Sisk wrote:
I have not verified this, but IF there is a lot of overlap of spans
between various timezones, perhaps a 'span registry' could be shared
between all the zone modules, thereby avoiding duplication of span objects.
I just ran a quick
On Thu, 13 Nov 2003, Matt Sisk wrote:
Now I'm starting to think we can have our cake and eat it too vis-a-vis
unique key generation for the spans.
If you don't mind, I'll take a crack at the templating in the tz module
generation script to construct the modules sharing the common data
On Thu, 13 Nov 2003, Rob Mueller wrote:
./perlbloat.pl 'use DateTime::TimeZone; $TZ{$_} =
DateTime::TimeZone-new(name = $_) for (DateTime::TimeZone::all_names)'
use DateTime::TimeZone; $TZ{$_} = DateTime::TimeZone-new(name = $_) for
(DateTime::TimeZone::all_names) added 12.7M
But of course
On Tue, 11 Nov 2003, Max Maischein wrote:
I saw in the CHANGES file that you added some other delta_* methods, but
didn't find them in the documentation, so I don't know about these, and
was too lazy to delve into the source for this :-)
These are for DateTime objects. I'm now regretting the
On Tue, 11 Nov 2003, Max Maischein wrote:
after some thinking about how to compare the inconvertible units, I
came up with an ugly hack that will work for most cases - the border
cases where it fails, are not yet detected, but I'm working on that. The
patch passes all my ad-hoc tests, I'll
On Thu, 13 Nov 2003, Rob Mueller wrote:
The only way really to provide a fast (to initialize, and access) timezone
DB is to either provide a DB (e.g. CDB, SDBM, etc) with the module, or have
something in the make process that creates such a DB based on the DBM
modules available on the user's
On Sat, 8 Nov 2003, Jonathan Swartz wrote:
I was trying to compare two durations, and came up with some surprises.
DB1 use DateTime;
DB2 $hour = DateTime::Duration-new(hours=1);
DB3 $minute = DateTime::Duration-new(minutes=1);
# Try comparing $hour and $minute
DB4 print ($hour
On Sun, 9 Nov 2003, Jonathan Swartz wrote:
Say I've got a function that takes a duration. I could
1) require the user to do DateTime::Duration-new(...);
2) take a listref argument containing the params, e.g. [days=1] and do the
creation myself
3) be flexible and take either argument,
On Thu, 6 Nov 2003, Joshua Hoblitt wrote:
Would this be better as a decorator that adds a format_datetime method?
(decorator setup)
DateTime::Format=Pg
print DateTime-now-format_datetime
2003-11-01 06:34:35+
Well, people using this might very well want to have DateTime act as a
On Wed, 5 Nov 2003, Matt Sisk wrote:
Just out of curiousity...why the '_datetime' suffix on these methods?
Isn't that redundant? Or was it assuming that these methods might be
showing up in classes outside of the DateTime namespace?
Because we can parse and format things that aren'ts
On Wed, 5 Nov 2003, Matt Sisk wrote:
Was there a compelling reason not to have a class method analagous to
DefaultLocale() for timezones, such as DefaultTimezone()?
Nope, no particular reason. But thinking about it, it seems like a bad
idea. Locale is something that I would think the end
On Wed, 5 Nov 2003, Hill, Ronald wrote:
I have recently updated the test scripts for the
Astro::Sunrise module and would like to incorporate these
changes into the DateTime::Event::Sunrise test suite. However,
I am unable to map an offset into a datetime timezone. Is
there a way to take an
On Wed, 5 Nov 2003, Matt Sisk wrote:
And as a convenience, I was suggesting this as equivalent:
$dt3 = $dt1-clone(%overrides);
If the set() method accepted a time_zone parameter (which is trivial to
add), wouldn't this be equivalent to:
$dt3 = $dt1-clone-set(%overrides);
??
-dave
On Thu, 6 Nov 2003, Rick Measham wrote:
But the same problem exists ... %parms will contain locale =
'en_AU', so your call to set is now:
$dt3-set( locale='en_AU', year=2003 .. second = 27, time_zone = '-1100',
locale='latvia'
);
So which locale gets used?
The second. It's
This is the officially blessed way of implementing DateTime.pm decorators.
I'll add this to the dev docs sometime soon.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
I finally sat down and wrote this, and it works.
The only trick is that authors of module intended to be mixin subclasses
of DateTime.pm need to call super::foo instead of SUPER::foo, because
I had to implement my own dispatch.
The alternative would have been much funkier code that broke the
0.2504 2003-10-25
- If a timezone module cannot be loaded, give a more useful error
message if the failure is due to a syntax error in the module, as
opposed to the specified time zone not existing. Based on a patch
from Alexey Mahotkin.
- Require Pod::Man 1.14+, so that head3/head4 markup
back to the list, where it belongs ...
-- Forwarded message --
Date: Tue, 21 Oct 2003 22:06:45 -0500 (CDT)
From: Dave Rolsky [EMAIL PROTECTED]
To: Daisuke Maki [EMAIL PROTECTED]
Subject: Re: Chinese Calendar Question
On Tue, 21 Oct 2003, Daisuke Maki wrote:
As you might know
On Mon, 20 Oct 2003, Flavio S. Glock wrote:
RFC: deprecate DateTime.pm *_rd_as_seconds
utc_rd_as_seconds
- used internally. DateTime::TimeZone should calculate this value from
utc_rd_values(), for compatibility with other calendars.
- does not use nanoseconds or leap seconds
Not using
On Mon, 20 Oct 2003, Joshua Hoblitt wrote:
On Mon, 20 Oct 2003, Whippo, Ryan K wrote:
Please remove me from list
Why did you resend this to him? No need to harass him.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Fri, 17 Oct 2003, Matt Wright wrote:
1) I've installed all of the pre-requisites for DateTime on a RedHat 9 box
and now when I try to perl Makefile.PL for 0.1705 I get:
Testing if you have a C compiler
make: *** No rule to make target `testub'. Stop.
I think this may be some screwiness
On Mon, 13 Oct 2003, Flavio S. Glock wrote:
How about a question for the FAQ?
http://perlmonks.org/index.pl?node_id=298788
Calculate down time of devices in prime time (only working hours, excluding
p_holidays)
by albertc on Oct 13, 2003 at 05:00 GMT+3
I have up down datetime
On Fri, 26 Sep 2003, Flavio S. Glock wrote:
Dave Rolsky wrote:
On Fri, 26 Sep 2003, Flavio S. Glock wrote:
I think this is wrong, because the RD day is an absolute
time and should only change at midnight, whatever
calendar module you use.
year/month/day should change, but RD
On Fri, 11 Oct 2003, Rick Measham wrote:
But some people have indicated that they'd like something a little
more flexible. Eugene van der Pijll suggested something like this:
my $dur = $dt1-difference( datetime = $dt2,
units= [ 'months', 'days' ] );
On Fri, 10 Oct 2003, Flavio S. Glock wrote:
That's true, because you are talking about a DateTime.pm method.
(delta_ymd would make sense in other calendars, that don't have
exactly 12 months.)
However, if DT::Duration is given 'year' units, it should not
automatically convert it to months,
On Sat, 11 Oct 2003, Joshua Hoblitt wrote:
DateTime::Duration should focus the Gregorian calendar. There is no
possible way to make it sufficiently generic to support all possible
calendars without giving up functionality useful in it's intended
context. The best we should do to support
On Sat, 11 Oct 2003, Daisuke Maki wrote:
Bah, answering my question...
my $rata_die = DateTime-new(year = 1, month = 1, day = 1);
my $from_rd = $rata_die + DateTime::Duration-new(days = $rd_days);
That works, as does:
{ package DateTime::RataDie;
sub utc_rd_values { @{$_[0]} }
}
On Thu, 9 Oct 2003, Flavio S. Glock wrote:
DT::SpanSet misses all these methods:
next( $dt )
previous( $dt )
current( $dt )
closest( $dt )
as_list
Is it ok to implement this in DT::SpanSet?
Please do!
/*===
House Absolute Consulting
www.houseabsolute.com
On Thu, 9 Oct 2003, Alexey Mahotkin wrote:
RM DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm SYNOPSIS
+ use DateTime; + my $datetime = DateTime-now(); + my $offset
= $tz-offset_for_datetime($datetime);
RM Rather than this, maybe we need to add a note to all modules
On Thu, 9 Oct 2003, Alexey Mahotkin wrote:
At the very least I think that the Synopsis must be updated.
I agree.
I believe that arguments description could be moved after the
function description. Current situation is an RPL-ism.
Huh? I think the current method descriptions are pretty
So there was some talk about this earlier and I was thinking about how
best to make this information available.
Currently, the default when subtracting datetimes is to break down the
duration into multiple parts, months, days, minutes, seconds, and
nanoseconds.
From the months piece we can
On Wed, 8 Oct 2003, Flavio S. Glock wrote:
Is this a problem with DateTime::Set Makefile.PL ?
This distribution has been tested as part of the cpan-testers
[...]
PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch -Iblib/lib
-I/usr/local/lib/perl5/5.6.1/mach
On Tue, 7 Oct 2003, Bill McCormick wrote:
Where is it? I checked a few mirrors and can't seem to find it.
Patience, young jedi. It takes a few hours, at least, for new uploads to
propogate to all the mirrors.
I posted a question a few days ago regarding getting the total number of
days (or
Hmm, I don't have much excuse for 0.1704 except that I'd just woken up ;)
0.1705 2003-10-07
[ BUG FIXES ]
- Subtracting one datetime from another was still broken, and my fix
in 0.1704 broke many other subtractions. Reported by Pierre Denis
again. Many thanks to Pierre for paying attention.
On Tue, 7 Oct 2003, Hill, Ronald wrote:
Thanks for that!! I just started looking at the sunrise module
to do some updates for preserving the timezone.
I just installed the new release of DateTime 0.1704
and all tests now pass for sunrise :)
0.1704 is really broken so try it again with
On Sat, 4 Oct 2003, [NS]Elgyn wrote:
Hi everybody,
I'm trying to make some custom locales and I've been having trouble getting the
register method to work. Even using the example code:
DateTime::Locale-register
( id = 'en_GB_RIDAS',
en_language = 'English',
0.04 2003-10-03
- The documentation incorrectly showed the DateTime::Locale-register
method as taking an array, rather than an array of hash references.
Reported by David Hood.
The code is identical to 0.03.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Fri, 3 Oct 2003, Michael and Alice Smith wrote:
Any ideas as to what the problem is??
# Failed test (t\20infinite.t at line 61)
# got: '-2147483648'
# expected: '2147483648'
# Failed test (t\20infinite.t at line 61)
# got: '-2147483646'
# expected:
On Thu, 2 Oct 2003, Mathieu wrote:
to my problem i didn't spotted ? If it's the proper way is there
any chance it will be included in a future release ?
It's definitely not the proper way, but I could be persuaded to add a
DateTime::TimeZone-zone_name_is_valid method.
-dave
On Thu, 2 Oct 2003, RIck Measham wrote:
$working_hours = new DateTime::Business::Week(
days = [1 .. 5],
start = {hour = 9, minute = 0},
end = {hour = 17, minute = 30}
);
and, for those with more complex weeks:
$working_hours = new DateTime::Business::Week(
On Fri, 3 Oct 2003, James M Snell wrote:
But the installation fails when it tries to run the tests:
C:\Environment\Perl\bin\perl.exe -MExtUtils::Command::MM -e
test_harness(0, 'blib\lib',
'blib\arch') t\00load.t t\01sanity.t t\02last_day.t t\03components.t
t\04epoch.t
On Sat, 4 Oct 2003, David Hood wrote:
0.04 2003-10-03
- The documentation incorrectly showed the DateTime::Locale-register
method as taking an array, rather than an array of hash references.
Reported by David Hood.
The documentation is still incorrect, using the example given in
This time I got the bright idea of adding those testy thingies.
0.05 2003-10-03
- Really make the documentation and code match! This time there are
even tests for this. Reported by David Hood (again).
- DateTime::Locale won't try to load a class if it already has a new()
method. This is so
On Tue, 30 Sep 2003, Steven J. Weinberger wrote:
If the RD is a value that only changes at midnight (as you noted
previously), then I think my order is right. The way you're suggesting
would change the RD if it's after sunset - wouldn't it? If you took a
DT::Calendar::Hebrew with an
On Mon, 29 Sep 2003, Steven J. Weinberger wrote:
- merged multiple READMEs into one, according to suggestion from Dave Rolsky
Actually, I was suggesting that this text belongs in the module
documentation itself. People won't see the README files after installing
the module
On Wed, 24 Sep 2003 [EMAIL PROTECTED] wrote:
This is a bit of a beef I have (as of earlier
today) with the Olson project. I've managed
to auto-map about 174 of the olson zones to
geographic places but am scared I may have to
do the rest by hand. I wish the names were
more along the lines
On Wed, 24 Sep 2003, Flavio S. Glock wrote:
Steven J. Weinberger wrote:
I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module,
but I'm having a problem. Below is my test code. The
results from the code are:
2003-09-24T10:42:00
2003-09-24T22:48:00
On Wed, 24 Sep 2003, Flavio S. Glock wrote:
This is what it looks like (tested!):
---
#!/usr/local/bin/perl
use DateTime;
use DateTime::Set 0.1202;
use DateTime::Event::Sunrise;
my $dt = DateTime-new(
year = 2003,
month = 9,
day= 24,
time_zone =
On Wed, 17 Sep 2003, Ron Hill wrote:
Ok, I see I can just do
my $dow = $dt2-day_of_week(
year = $dt-year,
);
The day_of_week() method DOES NOT TAKE ARGUMENTS!
I don't know what you think the code above does, but I can tell you that
all it does is return the day of the
On Fri, 19 Sep 2003, Joshua Hoblitt wrote:
The day_of_week() method DOES NOT TAKE ARGUMENTS!
I wonder if it's worth the overhead of checking for extraneous
parameters on all methods?
I'd rather try to keep accessors as quick as possible.
-dave
/*===
House Absolute
On Sat, 13 Sep 2003 [EMAIL PROTECTED] wrote:
For example, the Wednesday of the current week is:
my $today = DateTime-today;
my $wednesday = $today - ( $today-day_of_week - 3 );
How about adding a 'week' parameter
to the 'truncate' method:
print DateTime-today
0.1702 2003-09-18
- Added truncate( to = 'week' ). Suggested by Flavio Glock.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Wed, 17 Sep 2003, Hill, Ronald wrote:
I checked the docs for datetime and used them
F:\scriptsperldoc DateTime|grep day_of_week
File STDIN:
$dow= $dt-day_of_week; # 1-7 (Monday is 1) - also dow, wday
_0. So for example, this class provides both day_of_week() and
On Sat, 13 Sep 2003, Joshua Hoblitt wrote:
t/03components..Invalid offset: -124
# Looks like you planned 122 tests but only ran 55.
# Looks like your test died just after 55.
t/03components..dubious
Test returned status 255 (wstat 65280, 0xff00)
Scalar found where
0.1701 2003-09-15
[ BUG FIXES ]
- If from_epoch was given a fractional epoch with a floating point
value with more than 9 digits after the decimal point, the object
ended up containing a floating point number of nanoseconds. We now
truncate this number to an integer. Fixed by Joshua Hoblitt.
On Fri, 12 Sep 2003, Claus Färber wrote:
Dave Rolsky schrieb:
But there are only 24 hours in a day. What should DateTime do with hour
= 24?
It should be the beginning of the next day, of course (i.e. 00.00 on the
next day).
As ISO 8601 defines T2400, people might expect that behaviour
On Thu, 11 Sep 2003, Jesse Shy wrote:
let me make sure I have this correct. Under the proposed way all the
methods will take at least 1 argument -- a dt object that is the target
date -- and the routine will run completely on each call? No problem.
Right. If we wanted to optimize this later
On Fri, 5 Sep 2003, David Wheeler wrote:
Can you do another test for me (since I don't have a platform that
needs tzset)? Can you tell me how it affects use of local? Here's a
test script:
#!/usr/bin/perl -w
use strict;
use POSIX qw(tzset);
print scalar localtime, $/;
{
local
On Fri, 5 Sep 2003, David Wheeler wrote:
Bah. Thanks for that. Does this work?
#!/usr/bin/perl -w
use strict;
use POSIX qw(tzset);
print scalar localtime, $/;
{
local $ENV{TZ} = Asia/Tokyo;
tzset;
print scalar localtime, $/;
}
tzset;
print scalar localtime, $/;
yup
On Tue, 3 Sep 2003, Rick Measham wrote:
ALSO If we go this path or not, I'd prefer not to get plain undef back.
I'd like an indication that it was 'too hard to count', or that it was
'over 10,000'.
But undef means unknown, and if we can't count, we don't know how many
elements are in the set.
0.08 2003-09-04
- Negative durations were formatted as positive with Perl 5.00503.
Fixed by Flavio Glock.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Thu, 4 Sep 2003, Jonathan Leffler wrote:
I don't know if it is significant that I'm running in US/Pacific time
zone, which is 3 hours adrift from US/Eastern - it doesn't seem to be
that simple as running with TZ=US/Eastern does not alter the answers.
It's probably that simple. Simply
On Thu, 4 Sep 2003, Dave Rolsky wrote:
On Thu, 4 Sep 2003, Jonathan Leffler wrote:
I don't know if it is significant that I'm running in US/Pacific time
zone, which is 3 hours adrift from US/Eastern - it doesn't seem to be
that simple as running with TZ=US/Eastern does not alter
0.07 2003-09-02
- Added format_recurrence() docs. Implemented by Flavio Glock.
- Require DateTime::Event::Recurrence 0.03 to get hints on formatting
unbounded recurrences.
- Updated to work with newer versions of DateTime.pm and
DateTime::Span.
-dave
/*===
House
On Tue, 2 Sep 2003, Flavio S. Glock wrote:
If we want to document and specify that this is an error, then the size
should be infinite. Otherwise, if we might want to allow this in the
future, undef is correct. I don't feel too terribly strongly either way.
Ok. So let's document that it
On Fri, 22 Aug 2003, Joshua Hoblitt wrote:
I didn't look up the offset for Kiribati, actually, so thanks for the
correction.
I think the republic crosses at least 4 timezones.
Offsets of more than 12 hours aren't that strange; countries near the
international date line can choose on
[ moved onto the datetime list ]
On Thu, 21 Aug 2003, Guest via RT wrote:
This message about DateTime was sent to you by guest via rt.cpan.org
Full context and any attached attachments can be found at:
URL: https://rt.cpan.org/Ticket/Display.html?id=3303
The test t/infinite20.t
On Fri, 22 Aug 2003, Joshua Hoblitt wrote:
Can you change it so that the maximum offset is 24:00:00 and then check it
in?
There's no official limit on offsets are there? I can envision some
small country declaring an offset of greater then 24hours.
You can? That doesn't make much sense
On Sat, 23 Aug 2003, Eugene van der Pijll wrote:
The only problem is that DT::subtract_datetime doesn't use it. It
probably should. (It would be even better if there was an option to
calculate the difference in days secs. But the default should probably
be to return a difference of months,
On Tue, 19 Aug 2003, Flavio S. Glock wrote:
There are some cases when we don't know if a recurrence has any event at
all.
This may happen when you do an intersection of recurrences.
Otherwise, if they don't have a start and end, they are infinite, right?
But 'undef' is ok - I'll change that.
On Fri, 15 Aug 2003, Thomas Klausner wrote:
I'm getting strange results when subtracting dates from one another:
I make a new $dt object, setting the date to e.g. 2003-05-31. If I subtract
one month, I do not get 2003-04-30, but 2005-05-01, which seems wrong to me.
This problem only occurs
On Fri, 8 Aug 2003, Flavio S. Glock wrote:
Dave Rolsky wrote:
Anyway, does this API sound sane? And if it does, anyone have any really
clever implementation ideas? I have some scary ones involved AUTOLOAD and
constructing classes on the fly.
help me understand it -
Does something
0.1601 2003-08-07
[ BUG FIXES ]
- On platforms like Win32, where we can't find a finite() or
isfinite() function/macro, the DateTime::LeapSecond code wasn't being
loaded, so many tests failed. Reported by Ron Hill.
Thanks, Ron.
-dave
/*===
House Absolute Consulting
On Thu, 14 Aug 2003, Sam Vilain wrote:
A good point. This is needed so that when we serialize DateTime
objects, we don't need to serialize the timezone object too.
A good point - are you providing these methods for some of those
`other' :) persistence tools ?
Storable:
On Wed, 6 Aug 2003, Dave Rolsky wrote:
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
On Mon, 12 Aug 2003, Rick Measham wrote:
Attached is the above module. Unless there's strenuous objections I'll
CPAN it. I just wish for this and for ::Alias that we could hook in
better without messing with the internals.
While I'm thinking of it, I'd like to be able to set names and
On Tue, 12 Aug 2003, Claus Färber wrote:
Rick Measham [EMAIL PROTECTED] schrieb/wrote:
While I'm thinking of it, I'd like to be able to set names and
short-names for offsets.
For short names, that might be a good idea. But for long names, it would
break this:
| name
| Returns the name
On Sun, 10 Aug 2003, John Siracusa wrote:
If you only have a year and day of year, then having a from_day_of_year
constructor saves a _lot_ of calculation that end users have to do.
OTOH,
having to do 'DateTime-now(time_zone = local)' isn't very onerous
at
all.
...unless that's the
On Sat, 9 Aug 2003, Joshua Hoblitt wrote:
On the one hand, I agree. HiRes is bad, and hires is a bit worse.
OTOH, _so_ many people are already familiar with Time::HiRes, that having
our own variation on it may be confusing to as many people, or more, as
hires is.
So are we back to
On Sat, 9 Aug 2003, Joshua Hoblitt wrote:
I'm getting this failure from the CPAN dist and when I parse the Olson files myself.
Since 0.25 installed for me without errors at some point in the past I'm assuming
that this failure is being caused by a recent release of DT. Can anyone reproduce
On Fri, 9 Aug 2003, Rick Measham wrote:
On Sat, 2003-08-09 at 06:55, Dave Rolsky wrote:
So what I think we really want is this:
my $Wrapper = DT::Wrapper-wrapper( [$class1, $class2, $class3] );
Maybe my approach has some holes, but have a look at the attached and
see what you think
0.03 2003-08-06
- Once a locale is loaded, it is cached in memory, so that locale
objects are singletons. Calling methods that change the locale
registry, like register() or remove_alias(), clear that cache. This
should provide a noticeable speed boost when constructing many
DateTime objects
On Wed, 6 Aug 2003, Joshua Hoblitt wrote:
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.
I suspect updates to it will be quite
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
On Sun, 3 Aug 2003, John Siracusa wrote:
CGI-new(''): 5 wallclock secs @ 1869.16/s
(5.25 usr + 0.10 sys = 5.35 CPU)
CGI's constructor really doesn't do much at all, especially if there's no
query string or form submission to handle.
Date::Simple-new('2003-01-01'): 2 wallclock secs @
On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
$dt = DateTime-now_high_res();
or
$dt = DateTime-now( high_res=1 );
Thats a possibility too. Although to me that syntax would seem to
guarantee HiRes support to be available. I don't know if we want add
Time::HiRes as a dependency.
In
On Sat, 2 Aug 2003, Claus Färber wrote:
Joshua Hoblitt [EMAIL PROTECTED] schrieb/wrote:
OTOH, maybe I dont understand how your DateTime-hires( 1 ) call
would work without adding HiRes as a dependency.
It does - ...
IMO no DateTime::* module should depend on Time or Date modules outside
On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
In general, I have no qualms about dependencies if they're on
known-to-be-good modules _and_ they provide some useful functionality. In
this case, it's even less of a concern since Time::HiRes is a core module.
We can't import Time::HiRes's time
On Sat, 2 Aug 2003, Dave Rolsky wrote:
# use scalar time in case someone's loaded Time::Piece
-sub now { shift-from_epoch( epoch = (scalar time), @_ ) }
+sub now { shift-from_epoch( epoch = Time::HiRes::time, @_ ) }
Yep, looks right
I take it back. I thought we'd have now
On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
I take it back. I thought we'd have now() and hires_now(). I think
having nanosecond at 0 makes sense to most people.
We have an awful lot of constructors already. Maybe we should put this into
another package?
The more I think about
On Fri, 1 Aug 2003, Joshua Hoblitt wrote:
[1] Why UTC? Wouldn't Europe/Stockholm be more appropriate?
I committed this change to CVS but I think it may have uncovered some
sort of weird bug in DT::TZ. Could you run the tests from the CVS
version and let me know if they hang?
It's not
On Fri, 1 Aug 2003, Joshua Hoblitt wrote:
[1] Why UTC? Wouldn't Europe/Stockholm be more appropriate?
I committed this change to CVS but I think it may have uncovered some
sort of weird bug in DT::TZ. Could you run the tests from the CVS
version and let me know if they hang?
I take it
On Fri, 1 Aug 2003, Claus Färber wrote:
Dave Rolsky [EMAIL PROTECTED] schrieb/wrote:
That's going to take a while. I'd recommend using a year a little
closer to our own. DT::TZ ships with the changes pre-generated 30
years out, so dates in that range are quick.
Why does DT::TZ work
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
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
===*/
On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
- For this release, at least, the module always uses Dynaloader. This
is in order to see if this fixes a problem on Solaris where the
install library version of the DateTime .so file is loaded instead of
the newly compiled version in the blib
601 - 700 of 1076 matches
Mail list logo
