> yeah, but then we're bordering on a truly ridiculous number of
> constructors, most of which are just syntactic sugar. I'm afraid I'm
> going to go with Joshua's suggestion on this one. It "feels" right
> because the other constructors already take a time_zone parameter, so this
> one should to
It would be nice to have a link the sourceforge cvs or the cvs viewer from
datetime.perl.org/developer/.
http://sourceforge.net/cvs/?group_id=17187
and/or
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perl-date-time/
Cheers,
-J
--
On Thu, 27 Mar 2003, Eugene van der Pijll wrote:
> What standard? I didn't override iso8601(), only datetime(). Those are
> not synonymous any longer in ::Julian.
I see. I'm not sure if that's a good thing or not ;)
> If datetime() is there, as you say, as a convenient way to print both
> date
On Wed, 26 Mar 2003, Tim Bunce wrote:
> > > now_local()
> > > now_utc()
> > > today_local()
> > > today_utc
> >
> > Why not have the constructors take any timezone as an argument?
> >
> > ->now( 'utc' )
> >
> > or
> >
> > ->now( timezone => 'local' )
> >
> > or even
> >
> > ->now( timezone
Dave Rolsky schreef:
> On Wed, 26 Mar 2003, Eugene van der Pijll wrote:
> > - changed output of datetime() to 2000-01-01J00:00:00, to be
> > different from Gregorian dates.
> >
> > (Dave, what is the datetime() method for? It would be nice if every
> > Calendar module had at leas
On Wed, 26 Mar 2003, Eugene van der Pijll wrote:
> from the ::Julian changelog:
>
> 0.04 2003-03-13
> - changed output of datetime() to 2000-01-01J00:00:00, to be
> different from Gregorian dates.
>
> - removed bug in day_of_year calculation
>
> - removed "us
On Wed, Mar 26, 2003 at 09:54:11AM -0500, John Siracusa wrote:
> On 3/26/03 12:33 AM, Dave Rolsky wrote:
>
> > But if it's another attribute it needs a precision. I don't want to call
> > it "fractional seconds" and let each user decide, because that kills
> > inter-operability.
>
> Fractional s
> > Why not have the constructors take any timezone as an argument?
> >
> > ->now( 'utc' )
> >
> > or
> >
> > ->now( timezone => 'local' )
> >
> > or even
> >
> > ->now( timezone => 'floating' )
> >
> > If no arguments are specified you get still get UTC.
>
> You could, but I like the simplicity an
On Tue, Mar 25, 2003 at 09:42:30AM -1000, Joshua Hoblitt wrote:
> On Tue, 25 Mar 2003, Tim Bunce wrote:
>
> > On Mon, Mar 24, 2003 at 06:59:17PM -0600, Dave Rolsky wrote:
> > > On Mon, 24 Mar 2003, Joshua Hoblitt wrote:
> > >
> > > > > True. Though it'll be so commonly used I think it deserves a c
I have just uploaded DateTime::Calendar::Julian 0.04 and
DateTime::Calendar::Christian 0.01 to CPAN.
from the ::Julian changelog:
0.04 2003-03-13
- changed output of datetime() to 2000-01-01J00:00:00, to be
different from Gregorian dates.
- removed bug in day_of_ye
By the way:
Altitide --> Altitude
Hill, Ronald wrote:
> What I wanted to accomplish is to have the module accept a
> DateTime::Set object compute the rise/set times and return a new
> DateTime::Set object. Here is what I have done:
> sub as_set {
> my $self = shift;
> my $dt = s
Hill, Ronald wrote:
No, it is not CVS. This is the way it was in the Astro::Sunrise module
I can't remember where I got it from.
$VERSION = (qw$Revision: 0.01 $)[1];
Thanks John!! I have changed the module to use this syntax
Except that if you are not using CVS, there is no reason to do it at a
Hi Flavio,
I am working on the as_set portion of the sunrise module and I need your
advise. What I wanted to accomplish is to have the module accept a
DateTime::Set object compute the rise/set times and return a new
DateTime::Set object. Here is what I have done:
sub as_set {
my $self = s
>
> Dave Rolsky wrote:
> >
> > $VERSION = qw($Revision: 0.01 $) [1];
> >
> > That's not CVS, is it? If it is, please don't use it's
> revision numbers
> > directly (this is discussed in the dev docs I wrote).
No, it is not CVS. This is the way it was in the Astro::Sunrise module
I can't rem
Dave Rolsky wrote:
$VERSION = qw($Revision: 0.01 $) [1];
That's not CVS, is it? If it is, please don't use it's revision numbers
directly (this is discussed in the dev docs I wrote).
And even if Dave hadn't prohibited that mode of operation, the above code is not
backwards compatible to 5.005_
On 3/26/03 12:33 AM, Dave Rolsky wrote:
> On Tue, 25 Mar 2003, John Siracusa wrote:
>> Hrm, well, I'd actually be happy (for my purposes) with simply storing
>> fractional seconds as an integer somewhere. I don't care if fractional
>> durations are allowed, or if fractional seconds are used in dat
Joshua Hoblitt wrote:
>
> > > Is a leap second 12:01pm or 12:01am?
> >
> > It's 11:60pm
>
> Now that I think about it that makes a lot more sense. :)
11:59:60pm
- Flavio S. Glock
Dave Rolsky wrote:
> See, some people think it should be another attribute,
> other think that seconds should be floating point.
> Personally, I don't know.
> But if it's another attribute it needs a precision.
> I don't want to call it "fractional seconds" and let
> each user decide, becaus
> A warn/carp perhaps. Even so, though. I don't see why my parser needs to
> know anything about the formatter (it was given the input in good faith
> and happily parsed it), or why I should wrap my formatter to
> make sure things like '-0500' get 'normalized', while letting through
> other things.
* Joshua Hoblitt ([EMAIL PROTECTED]) [26 Mar 2003 19:07]:
> * Iain Truskett wrote:
[...]
> > +my $rdt = $dt->clone;
> > +$rdt->set_time_zone( 'UTC' );
> > +return $self->format_datetime( $rdt );
> I think this is dangerous... asking for -0600 and getting UTC just
> doesn't seem like th
> Index: lib/DateTime/Format/ICal.pm
> ===
> RCS file:
> /cvsroot/perl-date-time/modules/DateTime-Format-ICal/lib/DateTime/Format/ICal.pm,v
> retrieving revision 1.6
> diff -u -r1.6 ICal.pm
> --- lib/DateTime/Format/ICal.pm 16 F
21 matches
Mail list logo
