On Sun, 23 Nov 2003, Joshua Hoblitt wrote:
> On Sun, 23 Nov 2003, Dave Rolsky wrote:
>
> > This should be relatively simple to do, but I'm sure the current API makes
> > it easy. Basically, it'd be something like:
> >
> > (86400 * (Rata Die
On Sun, 23 Nov 2003 [EMAIL PROTECTED] wrote:
> > Someone should add that to the developer section on the website. :)
>
> Or even better to the "Mailing List" section of the website. I'm happy to
> make the change in CVS if that would help (pretty sure I still have
> access). But someone would ha
On Mon, 24 Nov 2003, David Garamond wrote:
> Is there a module/routine to do this? From .NET Framework SDK
> documentation: "Time values are measured in 100-nanosecond units called
> ticks, and a particular date is the number of ticks since 12:00
> midnight, January 1, 1 C.E. in the GregorianCalen
0.70 Nov 23, 2003
- Any validation call that used a callback leaked memory when using
the XS version. This was introduced in 0.67, when callbacks started
receiving a reference to the parameters as a second argument.
Reported by Eugene van der Pijll.
Since DateTime.pm (and maybe other DateTime m
On Sun, 23 Nov 2003, Todd Lorenz wrote:
> Mr. van der Pijll -- Thanks very much; your observations on
> Params::Validate do check out on my system. Is running the pure Perl
> version of PV considered deprecated, or is there otherwise any reason
> why I shouldn't use it?
It's much slower. I just
On Sun, 23 Nov 2003, Eugene van der Pijll wrote:
> Todd Lorenz schreef:
> > Could someone kindly confirm/debunk this?
>
> Confirmed. It seems that this is a memory leak in
> Params::Validate::validate(), possibly connected to optional parameters.
Try upgrading to Params::Validate 0.69.
-dave
On Fri, 21 Nov 2003 [EMAIL PROTECTED] wrote:
> Looks like there are some problems with the datetime list archive at
> archive.develooper.com, only messages from July 2003 are showing.
>
> I know there is also the nttp.perl.org archive, but unfortunately it
> doesn't seem to be threaded (very odd f
On Tue, 18 Nov 2003, Rob Mueller wrote:
> My point really is that if each timezone object only has to obey the method
> interface (which is about 10 methods and only 2 of those really require any
> calculations) and nothing inspects the objects internally or requires
> anything else from them, the
On Sun, 16 Nov 2003, Yitzchak Scott-Thoennes wrote:
> > I assume Perl uses these internally, so if none of them are defined, that
> > may cause problems.
>
> I think isnan is only used for <=>. isinf doesn't seem to be used at
> all. I think these aren't widely enough available for perl to make
On Sat, 15 Nov 2003, Rick Measham wrote:
> 1. Create DateTime::TimeZone::Lite.
> - This would return a subset of the Olson data that assumed the current
> rules extend infinitely in both directions.
> - This would not be a prereq, or be installed by DateTime itself.
> - I suggest we might make thi
On Sat, 15 Nov 2003, Max Maischein wrote:
> PS: I didn't know that this was some hornets nest I stirred up again -
> it was just a problem I wanted to solve for myself ...
Almost every facet of DateTime stuff is a hornet's nest. It seems simple
at first, but the deeper you get into it, the weird
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 f
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, 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
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 (a
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
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
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,
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 t
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 c
On Mon, 10 Nov 2003, Jonathan Swartz wrote:
> > Well, that still doesn't say which is bigger. For example, 1 month is
> > smaller than 30 days if your base date is Feb 1, but not if it's December
> > 1. It might be useful if you know that both durations were originally
> > derived from a single
On Mon, 10 Nov 2003, Jonathan Swartz wrote:
> Thanks. You might want to explain why comparison isn't offered (whether it's
> the reason I mentioned above, or another reason), and give some hints about
> what to do if you have to compare two durations (e.g. add them each to a
> single reference tim
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 Sat, 8 Nov 2003, Jonathan Swartz wrote:
> I was trying to compare two durations, and came up with some surprises.
>
> DB<1> use DateTime;
>
> DB<2> $hour = DateTime::Duration->new(hours=>1);
>
> DB<3> $minute = DateTime::Duration->new(minutes=>1);
>
> # Try comparing $hour and $minute
>
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
On Sat, 1 Nov 2003, Iain Truskett wrote:
> This any use?
>
> perl -MDateTime::Format=Mail -wle 'print DateTime->now->format_mail'
> Sat, 01 Nov 2003 06:34:12 -
>
> % perl -MDateTime::Format=HTTP -wle 'print DateTime->now->format_http'
> Sat, 01 Nov 2003 06:34:23 GMT
>
> % perl -MDateTime::Form
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 s
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 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
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 us
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 dateti
On Mon, 3 Nov 2003, Flavio S. Glock wrote:
> DT::Incomplete does not pass tests under 5.00503
>
> The error message is very weird.
> It seems that it is mostly related to requiring
> $var->$method();
> instead of
> $var->$method;
>
> I'm working on a fix.
I just checked in a fix.
-dave
/*=
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
===*/
On Fri, 31 Oct 2003, Autrijus Tang wrote:
> Okay, that's what I thought too. Expect it to be uploaded on a CPAN
> near you.
>
> Oh, and below is a DateTime patch to fix a critical flaw. Well, to me
> at least. :-)
Hmm, I could've sworn I looked this up and it said first tone. But I'll
trust yo
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 th
On Thu, 30 Oct 2003, Autrijus Tang wrote:
> Hi people. I would like to implement a DateTime::Functions module,
> similar to File::Spec::Functions, that exports now(), today() an
> d other class methods by default:
>
> use DateTime::Functions;
> print now->year;
>
> However, does it more p
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 doe
On Wed, 22 Oct 2003, Eugene van der Pijll wrote:
> DT prereq's:
> Class::Factory::Util 1.3 - prereq's of DateTime
> Params::Validate 0.52
> Test::More 0
> Time::Local 1.04
> Class::Singleton 1.03 - prereq of DT::TimeZone
> DateTime::Locale 0.03 - needed by DateTime
> Da
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:
>
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 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, 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 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
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 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
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, 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 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 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 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 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
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 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'
> #
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, 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, 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:
> 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 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 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
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, 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
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 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
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 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, 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, 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:
> 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 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
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 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',
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 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, 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 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, 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:
> 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 [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
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 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
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 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
0.1702 2003-09-18
- Added truncate( to => 'week' ). Suggested by Flavio Glock.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
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
>
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 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
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 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
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
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 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?
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 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, 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 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 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 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, 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
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 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
701 - 800 of 1439 matches
Mail list logo
