I could use a couple volunteers to review an article I'm writing about
date & time modules for perl.com.
The first few volunteers select will receive my gratitude, a brand new
email attachment, and that's about it.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
> On Thu, 6 Feb 2003, Rick Measham wrote:
>> I live in Australia and my timezone is +1100. But I host in the US someplace
>> where the machine has a timezone of -0600. I'd prefer to be able to set my
>> local timezone. Maybe ask the user on install but make a default of the
>> machine's local TZ?
On Thu, 6 Feb 2003, Rick Measham wrote:
> I'd argue against this (and possibly the code in TimeZone.pm for handling a
> time zone of "local").
>
> I live in Australia and my timezone is +1100. But I host in the US someplace
> where the machine has a timezone of -0600. I'd prefer to be able to set
On 6/2/03 9:36 am, Dave Rolsky at [EMAIL PROTECTED] spake thus:
> On Wed, 5 Feb 2003, Jonathan Scott Duff wrote:
>
>>> It might be best to just skip those tests if the DateTime::TimeZone
>>> package isn't installed, though.
>>
>> I haven't looked at the code yet, but would it be useful to ask th
On Wed, 5 Feb 2003 15:52:46 -0600 (CST), [EMAIL PROTECTED] wrote:
>> The DateTime tests do not fully exercise DateTime::TimeZone (nor would you
>> expect them to). So, how about including only those portions of DT::TZ which
>> are required to pass the DT tests. At a quick glance, that would be
>>
On Wed, 5 Feb 2003, Tim Bunce wrote:
> Er, I may well be missing something as I've not paid attention to this thread,
> but why not ship them both in the same distribution? Then some tests in t/*.t
> will test DT and some DT::DZ and both DT and DT::TZ being tested will be the
> ones in the distrib
On Wed, 5 Feb 2003, Jonathan Scott Duff wrote:
> > It might be best to just skip those tests if the DateTime::TimeZone
> > package isn't installed, though.
>
> I haven't looked at the code yet, but would it be useful to ask the
> user what their offset is from GMT, then create a dummy TZ from that
On Wed, Feb 05, 2003 at 10:58:52AM -0500, John Peacock wrote:
> Dave Rolsky wrote:
> >
> >Patches welcome ;)
> >
> >The time zone stuff is quite bizarre, I admin. But I really can't think
> >of a way to handle recurring rules (like ongoing DST rules) without being
> >able to date math, for example
Dave Rolsky wrote:
It seems rather arbitrary to only include Chicago and New York. I can
just see all the questions about why the others aren't included!
That's just the TZ's you tested, that's all. Any arbitrary bias lies in the
scope of the tests, not in my suggestion!
It might be best t
On Wed, Feb 05, 2003 at 03:52:46PM -0600, Dave Rolsky wrote:
> On Wed, 5 Feb 2003, John Peacock wrote:
> > The DateTime tests do not fully exercise DateTime::TimeZone (nor
> > would you expect them to). So, how about including only those
> > portions of DT::TZ which are required to pass the DT test
On Wed, 5 Feb 2003, John Peacock wrote:
> No, it's clear that the modules are deeply intertwined. My primary concern is
> that it is currently impossible to install both on a fresh machine without
> skipping the tests on one of the two (at least to begin with). In my mind,
> DateTime is the pare
On Wed, 5 Feb 2003, Yitzchak Scott-Thoennes wrote:
> >
> >No, Test::More is loaded by the "use Test::More" line. This is equivalent
> >to:
> >
> > BEGIN { require Test::More; Test::More->import; }
>
> But use_ok doesn't work right since the 'plan tests => 1' hasn't been
> done yet. There seems t
On Wed, 5 Feb 2003 00:40:01 -0600 (CST), [EMAIL PROTECTED] wrote:
>> p.s. You also need to apply the following minor patch
>>
>> --- t/01load.t.orig 2003-02-04 22:49:35.0 -0500
>> +++ t/01load.t 2003-02-04 22:49:48.0 -0500
>> @@ -14,7 +14,4 @@ BEGIN
>>
>> plan tests => 1;
>>
On Wed, 5 Feb 2003, Peter J. Acklam wrote:
> I think both behaviours ("normalization" and throwing an error)
> are useful, so how about adding options to the constructor, so one
> can use
>
>my $dt = DateTime->new( VALIDATE = 0,
>hour => 7,
>
On Wed, 5 Feb 2003, Rich Bowen wrote:
> > There's still lots left to do but what is written so far seems to work
> > reasonably well, so getting it out there into people's hands seems like a
> > good idea.
>
> Should I also release DateTime::Event::FourthofJuly for the sake of ...
> well, for the
On Tue, 4 Feb 2003, Dave Rolsky wrote:
> The first alpha release has been uploaded to PAUSE and should be on a CPAN
> mirror near you sometime soon. I've also asked to register the DateTime
> namespace (but no others yet).
>
> Please try them out and let me know what you think, what bugs you find
Dave Rolsky wrote:
Patches welcome ;)
The time zone stuff is quite bizarre, I admin. But I really can't think
of a way to handle recurring rules (like ongoing DST rules) without being
able to date math, for example. How else do you figure out the last
Sunday of October?
No, it's clear that t
17 matches
Mail list logo
