On Wed, 11 Jun 2003, Dave Rolsky wrote:
> On Tue, 10 Jun 2003, Joshua Hoblitt wrote:
>
> > I've started on milliseconds and microseconds support (DT::Duration to
> > start with). I hope nobody else has already done this.
>
> Um, don't we already have this with nanoseconds? What are you thinking
On Tue, 10 Jun 2003, Joshua Hoblitt wrote:
> I've started on milliseconds and microseconds support (DT::Duration to
> start with). I hope nobody else has already done this.
Um, don't we already have this with nanoseconds? What are you thinking of
adding?
-dave
/*===
House
I've started on milliseconds and microseconds support (DT::Duration to start with). I
hope nobody else has already done this.
-J
--
On Wed, 11 Jun 2003 [EMAIL PROTECTED] wrote:
> In DateTime::Duration:
>
> sub new():
> ...
> unless ( grep { $self->{$_} } qw( months days ...
> {
> $self->{sign} = 0;
> }
>
>
> and then:
>
> sub is_positive { $_[0]->{sign} == 1 ? 1 : 0 }
>
> which makes a zero-duration b
In DateTime::Duration:
sub new():
...
unless ( grep { $self->{$_} } qw( months days ...
{
$self->{sign} = 0;
}
and then:
sub is_positive { $_[0]->{sign} == 1 ? 1 : 0 }
which makes a zero-duration be "not positive",
because sign is zero.
- Flavio S. Glock
> > Can we just have an API that any module could potentially use?
>
> I think we need this, but we may also need a way to hook locales into
> DateTime::Locale.
And I think the next question is: "Should this be at run-time or should there be a
persistent registry?"
-J
--
> Can we just have an API that any module could potentially use?
Now thats just entirely too rational. Thank you for articulating my frustration.
> $locale = new My::Locale;
> $dt = DateTime->new(%date, locale => $locale);
I always assumed that we'd be getting this as it currently works for DT:
On Wed, 11 Jun 2003, Rick Measham wrote:
> I'd really like to not depend on Locale.pm other than as a loader for
> normal, included Locale methods.
>
> Can we just have an API that any module could potentially use?
I think we need this, but we may also need a way to hook locales into
DateTime::Lo
> So this is how it would work - you write custom locales, shove them in one
> of the @INC paths (preferably different to the DT::Locale install path) and
> add the LocalInstall module which is used to register your locales.
I'd really like to not depend on Locale.pm other than as a loader for
nor
> So this is how it would work - you write custom locales, shove them in one
> of the @INC paths (preferably different to the DT::Locale install path) and
> add the LocalInstall module which is used to register your locales.
It would be nice if modules could reside in arbitrary namespaces. For ex
That's too bad.
Anway, I am going to keep playing with this for a bit until I get all
of the functionality I want, then I can convert it to a re-based
thing.
-ben
On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote:
> On Tue, 10 Jun 2003, Ben Bennett wrote:
>
> > However
Hi everyone
It's clear that some folks are going to need custom locales whatever the
coverage of the core DT::Locale modules. It's also pretty clear that
DT::Locale isn't very friendly when you want to such locales:
Currently you have to add an entry into the DateTime::Locale::_locale method
arr
At 3:53 PM -0500 10/6/03, Dave Rolsky wrote:
Ok, I'm also _really_ confused about week_month(). What the heck is this
supposed to return? For July 5, 2001 it's returning 2, which seems wrong
to me, since July 5 is clearly part of the first week of July.
The comment mentions ISO but I find no refe
On Tue, 10 Jun 2003, Joshua Hoblitt wrote:
> > I played with P::RecDescent for Mason, and it is slow and a memory hog.
> > That's no dis to Damian, cause it's a great tool, but in most cases a
> > custom regex-based parser is way faster.
>
> I talked to Damian about it at Perl Whirl and he said he
> I played with P::RecDescent for Mason, and it is slow and a memory hog.
> That's no dis to Damian, cause it's a great tool, but in most cases a
> custom regex-based parser is way faster.
I talked to Damian about it at Perl Whirl and he said he's got plans for a major
rewrite. Although we all k
On Mon, 9 Jun 2003, Dave Rolsky wrote:
> > Attached is DateTime.diff. This file contains extensions to DateTime
> > to allow it to match the outputs of the ICU project.
> >
> > Strftime has also been patched to allow one to use methods as
> > strftime tokens: '%H' returns the same as '%{hour}'
> >
On Tue, 10 Jun 2003, Ben Bennett wrote:
> However, I have no idea how fast this is and how much memory it
> consumes. I will try to release what I have tonight (when I hope to
> have it in a more usable state).
I played with P::RecDescent for Mason, and it is slow and a memory hog.
That's no dis
> I am working on that. I decided to use Parse::RecDescent as a base.
> I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime
> complete?) and I have it parsing simple dates and times...
That document isn't anywhere close to what is defined by ISO 8601:2000.
http://www.pvv.ntnu.no/~nsa
Richard Evans wrote:
>> You're always welcome to provide a custom subclass like 'en_AU_RM' ;)
>
> Yes, that's why the language_territory_variant locales exist, and I'd bung
> them in a different @INC path to make it absolutely clear that they are
> custom locales.
Of course I havn't made it part
> Should it be part of the FAQ?
I'm not sure - I feel like it should probably be part of the developers docs.
Dave - should I add this under docs?
> I think you need to expand the Fictional section to talk about the
> suggested naming scheme.
I added some pieces of the original thread.
> > =it
Ah.
I am working on that. I decided to use Parse::RecDescent as a base.
I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime
complete?) and I have it parsing simple dates and times...
Next on my list is making it understand all of the weird and wonderful
things that Date::Manip can do
> FAQ answers should answer more questions then they generate,
> but two obvious questions leap out of that code...
>
> 1. Why is set_time_zone() needed for this DateTime example?
Good point - that should be added to the description.
> 2. Why use DateTime::Format::*MySQL* when the code may have n
Any progress on this?
-ben
On Wed, Apr 30, 2003 at 12:30:01PM +1000, Rick Measham wrote:
> > On Tue, 29 Apr 2003, Joshua Hoblitt wrote:
> >> I was thinking of something similar to the 'constant' syntax that
> >> quietly creates namespaces.
> >>
> >> use DateTime::TimeZone::Alias HST
A lot of the existing examples in the FAQ are from Date::Calc.
I can certainly take a whack at another module... where are you doing
this work? Is it part of the FAQ stuff or is it separate?
Before I leap in I would like to take a look at what you have so that
I can try to match the style.
I st
Unless anyone else is already doing a conversions document (or has
their heart set on doing it) I am willing to take a whack at it.
I've started on it (if you're talking about the migration document
mentioned earlier in this thread). I'd love if you want to take a
bite on one (or more) of the mod
On Monday 09 Jun 2003 2:52 am, Eugene van der Pijll wrote:
> There are many languages that have only a ISO 639-2 code. At the moment,
> two of them are supported in DateTime (sid = Sidama, and tig = Tigre),
> and one language without any ISO code (x-drs = sil-drs = Gedeo). All of
> these are Ethiop
Dave Rolsky wrote:
> On Tue, 10 Jun 2003, Rick Measham wrote:
>
>> > Anyway, I've
>> > applied it mostly, except that for era I used "ACE" and "BCE", because
>> > I'm really not comfortable favoring one religion over another inside
>> > the core code.
>>
>> That's cool .. I imagine that we'll cha
Unless anyone else is already doing a conversions document (or has
their heart set on doing it) I am willing to take a whack at it.
Modules to discuss conversions from:
- Date::Calc
- Date::Manip
- POSIX (and built-in Perl stuff e.g. Time::Local)
- TimeDate
- Time::Piece
Suggestions for
On Mon, Jun 09, 2003 at 03:32:39PM -1000, Joshua Hoblitt wrote:
> > But never-the-less the website could really do with a 'Migration' section.
> > I'll volunteer to do the initial write and everyone can have CVS access to
> > keep it up-to-date.
>
> Sounds good - I was hoping someone else would vo
On Mon, Jun 09, 2003 at 06:16:23PM -0500, Dave Rolsky wrote:
> On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
>
> > I just got back from Perl Whirl. Having spent most of the last week
> > plugging DT as a replacement for many of the examples given in the
> > talks, I think we need a converting to DT s
Added a missing head tag.
-J
--
On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
> Here is the document I started that lists the DT namespaces. It's been just sitting
> on my disk for several weeks so I figure I might as well get it finished. It's
> pretty short on details - although I don't think
Here is the document I started that lists the DT namespaces. It's been just sitting
on my disk for several weeks so I figure I might as well get it finished. It's pretty
short on details - although I don't think much more needs to be added. Any comments?
-J
--
=pod
=head1 DateTime::* Namesp
Dave,
Here is a small patch that allows you to create a DT::Language object by just calling
new on it (and thus not being trapped into the DT::Language namespace).
This should tie me over until locale is officially released. :)
-J
--
Index: lib/DateTime/Language.pm
* David Wheeler ([EMAIL PROTECTED]) [06 Jun 2003 01:43]:
> On Thursday, June 5, 2003, at 08:38 AM, Dave Rolsky wrote:
> >>I think that subclassing is one of Sean's goals for the Pod::Simple
> >>classes. I say we bug him about it. ;-)
> >
> >Subclassing Pod::Simple is easy. Subclassing P::S::HTML
34 matches
Mail list logo
