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
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 th
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
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 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
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
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
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
On Sun, 10 Aug 2003, John Siracusa wrote:
> On 8/10/03 9:39 AM, Dave Rolsky wrote:
> > DateTime.pm now sets the time zone to floating when it creates an object
> > in the from_object() method. I think it used to be UTC. I'll release a
> > new DT::TZ to handle this.
&g
0.65 Aug 07, 2003
- It is now possible to turn validation on and off at runtime. To
make this easier, it can be set via the PERL_NO_VALIDATION environment
variable, or the $Params::Validate::NO_VALIDATION global variable. Go
ahead, shoot yourself in the foot with it!
Per recent discussions of
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
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 reprodu
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.
>
&g
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
www
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. Al
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
> | Retur
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.
>
> ...u
0.2501 2003-08-10
- Fixed a test that failed because of a change in the DateTime.pm
from_object() API.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sun, 10 Aug 2003, John Siracusa wrote:
> On Sunday, August 10, 2003, at 04:12 PM, Joshua Hoblitt wrote:
> >> Okay, so maybe a new constructor then? DateTime->localtime()?
> >> Getting
> >> the current local time seems more common than, say, constructing a
> >> DateTime object from a day of the
So I started working on this and it's trickier than I thought. So rather
than go ahead and implement something really complicated only to find out
that it doesn't do what people want, I thought I should try to get some
consensus on functionality first.
The basic problem is that people want to be
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 oc
On Mon, 18 Aug 2003, Flavio S. Glock wrote:
> DT::Set v.0.09:
>
> DateTime::Set count()
>
> - returns scalar 'Inf' for recurrences;
This should probably be undef. We don't know whether or not recurrences
are infinite.
-dave
/*===
House Absolute Consulting
www.houseabsolu
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 t
On Tue, 19 Aug 2003, Joshua Hoblitt wrote:
> Comments?
Can you change it so that the maximum offset is 24:00:00 and then check it
in?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
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
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 month
Anyone have any idea why this might fail on Linux?
-- Forwarded message --
Date: Thu, 21 Aug 2003 04:17:23 -0400 (EDT)
From: Guest via RT <[EMAIL PROTECTED]>
To: AdminCc of cpan Ticket #3303: ;
Subject: [cpan #3303] test t20infinite.t failed on Linux mandrake 9.0
This message ab
[ 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:
> https://rt.cpan.org/Ticket/Display.html?id=3303 >
>
> The test t/infinite20.t (Dat
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 ch
-- Forwarded message --
Date: Tue, 26 Aug 2003 04:11:36 -0400 (EDT)
From: "[EMAIL PROTECTED] via RT" <[EMAIL PROTECTED]>
To: AdminCc of cpan Ticket #3303: ;
Subject: [Comment] Re: [cpan #3303] test t20infinite.t failed on Linux
mandrake 9.0
This message about DateTime was sen
On Tue, 2 Sep 2003, Bernhard Bauch wrote:
> hi!
> i installed DateTime, DateTime::Locale, DateTime::Format::MySQL from
> CPAN and tar.gzs.
> everytime i try to start my modperl-webserver i get this message:
>
> [Tue Sep 2 16:25:46 2003] [error] Can't load
> '/usr/local/lib/perl5/site_perl/5.6.1/a
On Tue, 2 Sep 2003, Tom Braun wrote:
> I'll take a stab at Date::Tolkien::Shire as soon as I can. You can take it
> as a good sign or a bad sign (since zero code has been written yet), but
> it's been on my todo list for 3 or 4 months. Are we all agreed that
> DateTime::Fiction::TBraun::TolkienS
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' i
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 Ab
The "DTEND" property doesn't appear to be the allowed in the recurrence
rules, according to RFC 2445, so I'm wondering why it's allowed as a
parameter to the DT::E::ICal->recur method, especially since it appears to
be the same as "until".
-dave
/*===
House Absolute Consultin
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 t
On Tue, 2 Sep 2003, Flavio S. Glock wrote:
> Dave Rolsky wrote:
> >
> > The "DTEND" property doesn't appear to be the allowed in the recurrence
> > rules, according to RFC 2445, so I'm wondering why it's allowed as a
> > parameter to the DT::E
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 se
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 se
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 ru
On Thu, 4 Sep 2003, David Wheeler wrote:
> > It's probably that simple. Simply setting the TZ env var probably
> > won't
> > do much. An app has to call POSIX::tzset() for that take effect.
>
> I find that for most date and time handling I do, just setting $ENV{TZ}
> does the trick -- except per
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, $/;
> {
>
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 localt
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 late
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
On Fri, 12 Sep 2003, Walter Torres wrote:
> I've been building my own date/time code in JS, Perl and PHP for the past 5
> years.
>
> I'd love to get involved with this effort to build a unified date/time
> library for Perl, and then maybe modify it for PHP.
>
> I can I come and play in here too?
Many of the examples where you show sets are much more efficiently done
with some simple math. For example, the Wednesday of the current week is:
my $today = DateTime->today;
my $wednesday = $today - ( $today->day_of_week - 3 );
In general, I don't think we should be encouraging people to use
On Sun, 14 Sep 2003, Joshua Hoblitt wrote:
> It's defined in the docs...
>
> =item * %V
> But it's not here...
>
> 'w' => sub { my $dow = $_[0]->day_of_week;
>return $dow % 7;
> },
>
> Was it documented and then not implemented?
Looks that way. I just
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 whe
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 Wed, 17 Sep 2003, Hill, Ronald wrote:
> I checked the docs for datetime and used them
> F:\scripts>perldoc 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 Thu, 18 Sep 2003, Syamala Tadigadapa wrote:
> Here is a simple solution (unless you are bent on doing it in a longer way
> using a date time class.)
Yeah, because letting others do the repeated work for you would be silly.
> sub jan1{
> my $y = shift;
> my $m = 1; $d = 1;
> $m = 11; $
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, 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
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, 20 Sep 2003, Syamala Tadigadapa wrote:
> Even in the datetime project code, may be you can add a method to supply the
> weekday of jan_first of present year if desired useful. May be a method can
$dt->clone->truncate( to => 'year' )->day_of_week
I don't think that justifies a new method
0.1703 2003-09-22
- truncate( to => 'week' ) caused a fatal error when the beginning of
the week was in the previous month. Reported by R. Mathews.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
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 lin
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-24T2
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_zo
On Wed, 24 Sep 2003, Flavio S. Glock wrote:
> sub _following_sunrise {
> [ ... initialize ...]
> my $tz = $dt->time_zone;
> my $loc = $dt->locale;
> [ ... some calculations ... ]
> $tmp_rise->set_time_zone( $tz ); # unless $tz->is_floating ???
> $tmp_rise->set_locale( $l
On Wed, 24 Sep 2003, Michael Fair wrote:
> Wouldn't the major city names be less prone to these kinds of disputes?
> Surely there will be times when some will be disputed but I don't see
> it happening so often as to be a major problem.
Yeah, that's why the Olson DB uses continents and cities onl
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 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 increm
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'
> # expecte
On Fri, 3 Oct 2003, Eugene van der Pijll wrote:
> Neither DateTime::Format::Excel nor DateTime::Event::Sunrise pass their
> own tests. They were both broken when the subtraction in DateTime
> changed, from returning days and seconds to returning y,m,d, h,m,s.
>
> DT::E::Sunrise uses the subtractio
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 Fri, 3 Oct 2003, Eugene van der Pijll wrote:
> > $dt1->subtract_datetime( $dt2 ); # current behavior
> >
> > $dt1->subtract_datetime( datetime => $dt2,
> > units => [ qw( days minutes nanoseconds ) ] );
>
> I didn't really like my API either, but a function with two
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::Busi
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\
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 exam
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, 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 (o
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 0
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
> > -I/usr/local/lib/p
On Thu, 9 Oct 2003, Alexey Mahotkin wrote:
> I've installed DateTime::TimeZone 0.2503 from CPAN under the Perl
> 5.8.1 and noticed the following glitches, which are fixed in the patch
> below and described in Changes.
Actually, there's intentionally no dependency on DateTime, since DateTime
depen
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.houseabsolut
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 m
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 s
On Thu, 9 Oct 2003, Hill, Ronald wrote:
> F:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
> 'blib\lib', 'blib\arch
> )" t\00load.t t\01basic.t
> t\00load.ok
> t\01basicNOK 1# Failed test (t\01basic.t at line 35)
> # got: '2000-06-19T07:54:00'
> #
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 deriv
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', 'd
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 m
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 { @{$_
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
>
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 & d
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 screwin
Some people here might find this interesting.
-- Forwarded message --
Date: Sat, 18 Oct 2003 13:41:03 +0200
From: Oscar van Vlijmen <[EMAIL PROTECTED]>
To: TZ-list <[EMAIL PROTECTED]>
Subject: Time zone boundaries for multizone countries
Resent-Date: Sat, 18 Oct 2003 07:41:17 -0400
On Sun, 19 Oct 2003 [EMAIL PROTECTED] wrote:
> I had this problem with RH9 also ... seems that perl's Unicode and
> RH9's Unicode support got all tangled up. I fixed it by changing
> LANG=en_US in my bashrc to just 'LANG='. I read that somewhere ...
> anyway it works! I think perl downgraded it's
On Mon, 20 Oct 2003, Rick Measham wrote:
> First version released to CPAN yesterday.
>
> Provides LMT (Local Mean Time) for DateTime.
>
> When given a longitude, this module calculates the Local Mean Time Time Zone.
There's one problem with this modules. DT.pm relies on the time zone
object retu
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
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
===*/
601 - 700 of 1292 matches
Mail list logo
