I wrote a custom HTML converter because Pod::Html produces such awful
HTML, and I wanted to customize some of the link handling. I also removed
all the "QUESTION" bits and stuck them in docs/todo.pod in the repository,
since they don't really add anything to the FAQ for most readers.
-dave
/*==
On Mon, 9 Jun 2003, Eugene van der Pijll wrote:
> So you would have to add some three-letter codes, at least. But I don't
> think it is necessary to include the ISO 639-2 codes for English, German
> etc.
That'd get real confusing. I think we should include them for all
languages, not just those
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 section in the FAQ or a
> separate document dedicated to this.
>
> For e
So there's an article on Oreillynet right now about Java's Date class and
other related classes like Calendar and TimeZone. While Java seems to do
more or less everything DateTime does, the API is absolutely abysmally
bad. It's awkward, unidiomatic, and requires lots of structural code.
http://w
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: &#
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 change it in short-order to get i
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
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: &#
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
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
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
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
On Wed, 11 Jun 2003, Tim Bunce wrote:
> And I'll repeat my (carefully worded) statement that "A single
> regex could handle all formats that follow the ISO 8601 general
> left-to-right decreasing resolution style, with assorted optional
> punctuation, plus optional appended TZ."
In fact, this'd b
On Wed, 11 Jun 2003, Ben Bennett wrote:
> I will do that. I didn't realize that it was so useful (too many damn
> /date|time*/i modules).
>
> I haven't looked inside yet, but this might be a good base for a more
> generic parser (Date::Manip is pretty gross).
Date::Manip's code is less than opti
On Wed, 11 Jun 2003, Tim Bunce wrote:
> > > And I'll repeat my (carefully worded) statement that "A single
> > > regex could handle all formats that follow the ISO 8601 general
> > > left-to-right decreasing resolution style, with assorted optional
> > > punctuation, plus optional appended TZ."
>
On Thu, 12 Jun 2003, Rick Measham wrote:
> I can understand why we look like we need all this stuff for milli-,
> micro- and nano-seconds, but it is exactly what I was scared of when
> we were talking about sub-second support. Nano-, Milli- and Micro-
> seconds are not different things like hours
On Thu, 12 Jun 2003, Rick Measham wrote:
> At 4:28 PM -0500 11/6/03, Dave Rolsky wrote:
> >5.00503 is the goal for all DateTime modules, and anyone writing a DT
> >module should have a damn good reason for _not_ supporting it. qr// does
> >indeed work with 5.00503.
>
>
On Thu, 12 Jun 2003, Rick Measham wrote:
> At 5:04 PM +1000 6/6/03, Rick Measham wrote:
> >The attached module is a time-only implementation of DateTime.
>
> Did this:
> 1) escape the radar,
> 2) not interest anyone,
> 3) handle everything so embarassingly wrong that none of you
> kind-hearted fol
On Thu, 12 Jun 2003, Rick Measham wrote:
> At 4:36 PM -0500 11/6/03, Dave Rolsky wrote:
> >No, if anything, we'll can the fractional_second constructor parameter.
> >Nanoseconds are here to stay, because I don't want to add "bigfloat" to
> >the mix, and
On Thu, 12 Jun 2003, Rick Measham wrote:
> At 4:59 PM -0500 11/6/03, Dave Rolsky wrote:
> >Yeah, me. DT.pm uses qr// internally and I always run tests on 5.00503,
> >5.6.1, and 5.8.0 before each release.
>
> It wan't a qr//, it might have been a 'our', but I d
On Wed, 11 Jun 2003, Joshua Hoblitt wrote:
> A new 2nd tier namespace for wrapper classes.
>
> DateTime::Wrap or DateTime::Wrapper
>
> DateTime::Wrapper::SubSecond will accept parameters for resolutions from
> 10 to 10^9 subseconds. With corresponding methods returning these
> units.
>
> Comments
On Wed, 11 Jun 2003, Joshua Hoblitt wrote:
> > > DateTime::Wrapper::SubSecond will accept parameters for resolutions from
> > > 10 to 10^9 subseconds. With corresponding methods returning these
> > > units.
> > This seems like overkill for something which will basically do:
> >
> > my $nano = $p
On Thu, 12 Jun 2003, Joshua Hoblitt wrote:
> > On this significant date of Friday 13th :-) I'd like to announce that I've
> > made Debian packages for some of the DateTime modules (and some which were
> > needed as dependencies) which you might find handy if you use this
> > platform.
>
> This is
On Fri, 13 Jun 2003, Jaldhar H. Vyas wrote:
> I made these to support my work on DateTime modules for Hindu calendars
> (which incidently are stalled as I research Sanskrit texts) but
> unfortunately I don't have the time to maintain them in Debian itself but
> if there are any Debian maintainers
On Wed, 4 Jun 2003, John Peacock wrote:
> I think there might be another Win32ism at play here. At the start of the test
> file, there are the following lines (with their "value" after the comment):
>
> my $posinf = 100 ** 100 ** 100; # "1.#INF"
> my $neginf = -1 * $posinf; # "-1
On Thu, 12 Jun 2003, Richard Evans wrote:
> a) If you're using the DateTime::Locale namespace:
>
> DateTime::Locale->register_locale(de_DE_RIDAS1 =>
> 'deu_DE_RIDAS1',
> 'ger_DE_RIDAS1',
>
Can people try to compile DateTime.pm on various platforms that aren't
Linux, BSD, or Win32, and let the list know if it works. I will be trying
Mac OSX and Solaris via the SF compile farm, but I don't have access to
other propietary Unix variants, or VMS, QNX, or other weird things like
that.
-
On Fri, 13 Jun 2003, Dave Rolsky wrote:
> Can people try to compile DateTime.pm on various platforms that aren't
> Linux, BSD, or Win32, and let the list know if it works. I will be trying
> Mac OSX and Solaris via the SF compile farm, but I don't have access to
> other pr
On Fri, 13 Jun 2003, Dave Rolsky wrote:
> Can people try to compile DateTime.pm on various platforms that aren't
> Linux, BSD, or Win32, and let the list know if it works. I will be trying
> Mac OSX and Solaris via the SF compile farm, but I don't have access to
> other pr
0.19 2003-06-13
- The name() method will now always return something that can be used
to recreate the original object by calling DateTime::TimeZone->new().
The only class which changed was DT::TZ::Floating, but the fact that
name() is guaranteed to work in recreating the object is an API
chang
On Fri, 13 Jun 2003, John Peacock wrote:
> Dave Rolsky wrote:
> > On Wed, 4 Jun 2003, John Peacock wrote:
> >>my $nan = abs($posinf - $posinf); # "1.#QNAN"
> >>
> >
> > Any updates on this? The Win32 problems are the only thing holding me
>
On Fri, 13 Jun 2003, Hill, Ronald wrote:
>
> Hi Dave,
>
> >
> > Can people try to compile DateTime.pm on various platforms that aren't
> > Linux, BSD, or Win32, and let the list know if it works. I
> > will be trying
> > Mac OSX and Solaris via the SF compile farm, but I don't have
> > access to
On Fri, 13 Jun 2003, John Peacock wrote:
> Dave Rolsky wrote:
> > Ok, I applied this. Does this mean all tests pass on Win32 now?
> >
>
> I don't know; I'm at home (Linux only, thanks) and not at work. I'll get the
> latest CVS and double check on Mon
On Fri, 13 Jun 2003, Joshua Hoblitt wrote:
> > That's cool. I'll be going to YAPC tomorrow anyway, so I'll have plenty
> > to keep my busy.
>
> I don't suppose you'll apply my DT::Language patch before then? :)
I'll apply it before the next release unless DT::Locale is finished first.
-dave
/
Changes since 1.04, which comes with Perl 5.8.0:
1.05 2003-06-03
This version is nearly identical to version 1.04, which is included in
the Perl core, but it removes the use of "our" in order to make the
code backwards compatible with Perl 5.00503. It probably works with
earlier versions of Pe
This release adds some more docs and brings the code into sync with
bleadperl.
I haven't had any reports of problems with this code yet so I expect to
send patches to p5p real soon now.
1.06 2003-06-04
- A bug in the handling of negative offsets from UTC could lead to the
return of invalid tim
On Sat, 7 Jun 2003, Rafael Garcia-Suarez wrote:
> Dave Rolsky wrote:
> > This release adds some more docs and brings the code into sync with
> > bleadperl.
> >
> > I haven't had any reports of problems with this code yet so I expect to
> > send patc
On Wed, 11 Jun 2003, Joshua Hoblitt wrote:
> namespace? I believe there is some president for this, for example DBI,
He means "precedent" ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Mon, 16 Jun 2003, Joshua Hoblitt wrote:
> I am of the opinion that when go ahead and add this doc to CVS. If we
> hear from "modules" that they have an objection then we can change it
> then. Or should we start a betting pool on when we'll get a response?
> :)
Yeah, go ahead and add it. I'm
On Mon, 16 Jun 2003, Ben Bennett wrote:
> I really like the new is_X subs, although in the case of the
> is_alias() would it make sense to return the target of the alias?
No, any method that starts with is_ should return a boolean value (or only
be guaranteed to return such a thing). If you need
On Mon, 16 Jun 2003, Hill, Ronald wrote:
> t\05set...ok
> t\05tzNot an ARRAY reference at
> F:/perl/site/lib/DateTime/TimeZone.pm line 146.
> # Looks like your test died before it could output anything.
> t\05tzdubious
> Test returned status 255
I put these on datetime.perl.org. They're linked from the resources page.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Well, while I was at YAPC my server crashed over and over. Whee! So I
may have missed email. If there was something that someone wanted me to
respond to, and I don't do so by next Monday or so, please let me know
about it.
-dave
/*===
House Absolute Consulting
www.houseabs
This fails on both 5.00503 and 5.6.1.
For 5.6.1, installing the latest Math::BigInt from CPAN fixes this, but
unfortunately the latest distro has a missing file that causes it not to
pass its tests.
On 5.00503, other Math::BigInt tests fail which seems to just be a
backwards compat problem. Ugh.
On Sat, 21 Jun 2003, Richard Evans wrote:
> The conversion script is a horrible mess - it's part of the other locale stuff
> I was (maybe still am) doing, and uses 10 other modules that are in a state
> of flux ATM. I also have a horrible feeling the ICU .xml file format had
> changed last time I
On Sat, 21 Jun 2003, Richard Evans wrote:
> I'm suggesting I donate all the DT::Locale code to the DT project next week,
> then anyone with CVS access can hack away to their hearts content - I
> wouldn't be in "control" of it any more.
>
> If you want to give me CVS access as well, that's entirely
On Sat, 21 Jun 2003, Ben Bennett wrote:
> I saw that mail, but I meant yet another constructor that will take an
> ISO week number and day number (within the week) and a "year"
> construct the appropriate date.
>
> Note that the year given may not be the actual year the date falls in
> but is rath
On Sat, 21 Jun 2003, Richard Evans wrote:
> The one exception to this would be additions, and in that case I can generate
> any new locales for the time being - I'm not saying that I'll never release
> the generator code, simply that it's not feasible in the short term.
Why isn't it feasible? Ju
On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
> > I can't think of any other usage which necessitates such a constructor.
>
> strptime needs it.
Actually, if we're going to emulate the C library's strptime() then it's a
_different_ week number. In fact, there's two different ones strptime()
handles
On Sat, 21 Jun 2003, Ben Bennett wrote:
> - Module name not settled yet
What other name would you use? DT::F::ISO8601 seems pretty logical to me.
Why not check it in with this name?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
> We are thinking about having two different modules. Or I'm willing to
> throw mine away if it's just going to be superfluous.
>
> DateTime::Format::ISO8601::Complex
> DateTime::Format::ISO8601::Simple
>
> The question is should there be a DT::Format::I
Any progress on this? If not, I'll probably throw in a hack in the
DateTime.xs to just not compile _normalize_seconds on Win32, because I
really want to make a new release of DateTime.pm, and I don't want to wait
much longer for the Win32 fixes.
-dave
/*===
House Absolute Co
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> > There is a DateTime->from_day_of_year constructor.
>
> In the CVS version - what is the ETA for the next release?
The only thing I've been waiting on for a while is a resolution of the
Win32 problems. If we can't find a proper fix very soon (like by
On Sat, 21 Jun 2003, Jesse Shy wrote:
> Maybe I should include my ugly little hack for Data::Calc and how I am
> employing it an a live application?
Please do. I think that basing what we start with on existing, in-use
code, is definitely a reasonable idea.
While I know that DateTime::Business
On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
> 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. :)
You'll be happy to know
On Sat, 21 Jun 2003, Bruce Van Allen wrote:
> There's been quite a bit of talk about how to handle date and time for
> business & fiscal applications. I urge _not_ trying to create a
> comprehensive module.
>
> Instead, an extensible framework, within a DT::Business or DT::Fiscal
> namespace, coul
On Sat, 21 Jun 2003, Jesse Shy wrote:
> I would like to tackle number one below by porting what I have from
> Date::Calc; I am taking this as implicit permission to use the
> DT::Business::FiscalYear namespace for this OK?
That seems like the best namespace to me. Anyone else have thoughts on
th
On Sat, 21 Jun 2003, Richard Evans wrote:
> On Saturday 21 Jun 2003 4:16 am, Dave Rolsky wrote:
> > On Sat, 21 Jun 2003, Richard Evans wrote:
> > > The one exception to this would be additions, and in that case I can
> > > generate any new locales for the time being
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> > It is not clear to me what a value like 2003-06 would mean. Is it "a
> > timepoint somewhere in June 2003" (an imprecise datetime), or is it "all
> > timepoints in June 2003" (a datetime span)?
>
> This is why I feel the need for time only objects or
On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
> DT::TZ::LINKS is still the only internal structure that is modified.
Yes, but you access @DT::TZ::ALL as well.
> > almost certainly does not belong in a module called Alias! Why does
> > it
>
> Probably not - but what ever module handles the aliasing
On Sat, 21 Jun 2003, Bruce Van Allen wrote:
> One thought: A "fiscal year" is type of calendar, and as the (long-ago)
> DT consensus was that all "calendars" are adopted fictions, perhaps it
> should be DT::Calendar::FiscalYear. The API would have to be somewhat
> different from the existing DT::C
On Sun, 22 Jun 2003, Eugene van der Pijll wrote:
> Businesses in Israel, Iran and in the Arab world probably use a business
> calendar based on the Hebrew, Jalali and Hijira calendars. It would be
> nice if one module could be used for the Gregorian calendar and for
> these three calendars.
Actua
On Fri, 20 Jun 2003, Eugene van der Pijll wrote:
> Peter J. Acklam schreef:
> > I could have sworn the difference was 0 seconds between 1970-01-01
> > and until the leap second in June 1972. I should have checked
> >
> > ftp://maia.usno.navy.mil/ser7/tai-utc.dat
>
> By the way, according to the
On Sun, 22 Jun 2003, Jesse Shy wrote:
> OK , I am coding up the port from Date::Calc::Fiscal right now. I should
> have something for y'all to look at by the end of the day ( I hope ). I
> will still have to write docs and test. It will have only 2 methods right
> now, day_fiscal_year - if Mar 1 i
On Sun, 22 Jun 2003, Ben Bennett wrote:
> I used to live in Saudi Arabia and the weekend was on Thursday and
> Friday (I don't know what calendar businesses used but I will ask my
> father).
If it was on Thursday and Friday it was still following the Gregorian
calendar though. That was my basic
On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
> Should I add the namespaces doc to web/htdocs/developer/?
Sure, please do.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sun, 22 Jun 2003, Dave Rolsky wrote:
> On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
>
> > Should I add the namespaces doc to web/htdocs/developer/?
>
> Sure, please do.
BTW, you should use Pod::Simple::HTML for the conversion, not pod2html
that comes with Perl. The latter pr
On Sun, 22 Jun 2003, Richard Evans wrote:
> * Added new locale generator (ICUGenerator.pl) which is not derived from my
> other work - this is largely untested. Locale data is not supplied and must
> be generated from ICU .xml sources.
Thanks, this looks great.
> * All manually edited code remov
On Sun, 22 Jun 2003, Ben Bennett wrote:
> Check out Dave's work on the POD to HTML stuff for the FAQ for a
> start...
Actually, the FAQ is much more complicated. For the other docs I've just
been doing
perl -MPod::Simple::HTML -e \
"Pod::Simple::HTML->filter(shift)" \
and then hand-e
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> > > DT::TZ::LINKS is still the only internal structure that is modified.
> >
> > Yes, but you access @DT::TZ::ALL as well.
>
> I was necessary to verify that what an alias was pointing to was valid.
> Once the dependency was already there I implemented
On Mon, 23 Jun 2003, Joshua Hoblitt wrote:
> I think you probably never got the original email with this patch (it
> was sent while you reported having difficulties). The general idea was
> to do something like the following and then update the calendar docs so
> nanosecond precision is always pr
On Wed, 25 Jun 2003, Ben Bennett wrote:
> my $short = DateTime::TimeZone->short_name_for_datetime($dt);
This is an object method, not a class method.
> On a related note, while trying to chase this problem I noticed that
> DT::TZ->span_for_datetime() compares $type to "UTC" to determine $end,
>
0.21 2003-06-25
- Switched to Module::Build, which should fix the installation
problems caused by very long Makefile lines on some platforms.
- Fixed a bug in finding the correct data for a given datetime. This
could occur when calling set_time_zone on an object that was very
close to a DST
Ugh, my release management skills stink. Hopefully there won't be another
release with this many changes at once for a _long_ time (or better yet,
never!).
I gave up on Win32 and made a hack to skip the failing test. I figure
that the infinite datetime stuff is marginal enough that it's better t
On Thu, 26 Jun 2003, Flavio S. Glock wrote:
> yet another object = slower program
At least for DateTime.pm, I think this is enough for me to not use it.
Given the fact that the internals work fine now, I don't see a good reason
to change them.
It seems to me that converting between calendars i
[ moved ot the list ]
On Thu, 26 Jun 2003, Joshua Hoblitt wrote:
> In the case of DT::C::Egyptian inheritance makes a lot of since. The
> Gregorian calendar only needs minor tweaks to function as the Egyptian
> one. Why should everyone have to reinvent the entire wheel instead of
> sub-classing
On Thu, 26 Jun 2003, Joshua Hoblitt wrote:
> > Hmm, this is a problem. I'm really not sure subclassing makes that much
> > sense here. At the very least, you probably need to provide your own
> > new() method.
>
> The DT constructor is pretty large - not much fun.
It can be broken up into multi
On Fri, 27 Jun 2003, Flavio S. Glock wrote:
> You could use the name "DateTime::File::Ics"
> or "DateTime::File::ICal"
What would the DT::File namespace be for? I don't want to arbitrarily add
new namespaces.
This sounds to me like two modules: DT::Format::ICS and DT::Event::ICS.
-dave
/*===
On Sat, 28 Jun 2003, Rick Measham wrote:
> This is just for comment. As per my previous email, this module allows
> one to compare durations when given a reference point. I'm not real
> happy with the method names, and I've just called it
> DateTime::Duration::Compare for the time being.
> DateTim
On Sat, 28 Jun 2003 [EMAIL PROTECTED] wrote:
> # Failed test (t/01datetime.t at line 87)
> # got: 'TZID=-0100:19000101T15'
> # expected: '19000101T16Z'
> # Looks like you failed 1 tests of 37.
>
> my $dt = DateTime->new(
> year => 1900, hour => 15, time_zone => '-01
On Sat, 28 Jun 2003, Joshua Hoblitt wrote:
> I received this bug report on one of my modules. Is this a known
> problem with Module::Build or nmake?
Module::Build doesn't use make, so instead of "nmake test" you need to do
"./Build test" or ".\Build test".
-dave
/*===
Hous
I thought that this was going to be the parent namespace, not the actual
module name, right?
I don't think we should co-opt the whole namespace for a module which just
provides a few simple pieces of functionality.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Sun, 29 Jun 2003, Joshua Hoblitt wrote:
> I just noticed your on MJD's lightning talk list for OSCON. What are
> you going to cram into 5 minutes? :)
Um, I dunno. I figured I'd write it that day or something. I'm mostly
planning on just telling people what the project is and why it's a good
On Mon, 30 Jun 2003, Ben Bennett wrote:
> The nits:
> 1) The following doesn't work because add_duration() doesn't return
> the object, but rather falls through and returns the number of
> nanoseconds in the final object:
> --
> my $dur = DateTime::Duration->new(months => 3)->add(hour
On Mon, 30 Jun 2003, Flavio S. Glock wrote:
> > Well, maybe. Right now the constructor is really simple, which is good.
> > More functionality is nice, but so is simplicity.
>
> use DateTime;
> my $dt = DateTime->now;
> my $dur = sub { $_[0]->add( months => 3 )->subtract( hours => 3 ) };
> print
On Mon, 30 Jun 2003, Ben Bennett wrote:
> I am totally mystified. I read "If any of the numbers are negative,
> the entire duration is negative." as indicating that the individual
> signs don't matter.
>
> I think the error is on DT::Duration line 52:
> $self->{minutes} = abs( ( $p{hours} * 60
On Mon, 30 Jun 2003, Matt Sisk wrote:
> So, yes, the implication is that:
>
> $dur = DT::Dur->new(days => 2, months => -1);
>
> would indeed behave differently than:
>
> $dur = DT::Dur->new(months => -1, days => 2);
>
> So long as the behavior (intrinsic to durations) is well documented I thin
On Mon, 30 Jun 2003, Matt Sisk wrote:
> Found the parse_recurrence docs in the CVS, thanks.
>
> However, there's a good reason the format_recurrence method is not
> documented...it doesn't exist.
>
> Are there plans to implement this?
This is hard, since recurrences are implemented as closures/co
On Mon, 30 Jun 2003, Joshua Hoblitt wrote:
> > Why not:
> >
> > $dur1 = new DT::Dur( days => 2 );
> > $dur2 = new DT::Dur( months => 1 );
> > $dur3 = $dur1 - $dur2;
> > $dur3->add( days => 3 );
> >
> > If you add $dur3 to a date, it would add 2 days and
> > subtract a month, then add 3 days again.
On Tue, 1 Jul 2003, Hill, Ronald wrote:
> >
> > You can do "./Build dist". The latest Module::Build beta
> > (0.18_02) also
>
> I tried this. Here is the result.
> Creating DateTime-TimeZone-0.21.tar.gz
> Can't locate object method "create_archive" via package "Archive::Tar" at
> F:\pe
> ild/Base
On Tue, 1 Jul 2003, Joshua Hoblitt wrote:
> Agreed. I think it should boil down to recurrences and durations.. If
> most people need that functionality then lets call your module
> DT::F::ISO8601 and I'll use ISO8601::Simple. If they don't then I'll
> take ISO8601 and you can use ISO8601::Compl
On Thu, 3 Jul 2003, Ben Bennett wrote:
> I am okay with this decision. However Joshua's parser does not allow
> selection of which pieces of the spec are applicable so you can have
> ambiguous cases.
>
> Anyway, I will rename my parser to
> DateTime::Format::ISO8601::Complete and release it.
Ugh
On Thu, 3 Jul 2003, Ben Bennett wrote:
> Well mine currently does that and parses durations...
>
> Joshuas can probably be changed to do so, but I am not motivated to
> do the work.
So, no offense to Joshua, I think yours should be the one with the
DT::F::ISO8601 namespace. I don't see the need
On Thu, 3 Jul 2003, Ben Bennett wrote:
>
> I am not sure what interface to use for the advanced features of the
> ISO8601 parser I wrote. Right now I use a quick hack to make it work
> so I can test the parser. It should be easy for me to change the
> interface to something sane, I just don't kn
On Thu, 3 Jul 2003, Jesse Shy wrote:
> I think I got everything up that is needed.
I want to change the API a bit, to be more like the other DT modules.
Right now it's not even close to the other modules.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
=
On Thu, 3 Jul 2003, Ben Bennett wrote:
> There is a lot to work out, but once the interface is clear it should
> be very quick to implement.
>
> Do you have any suggestions for what the interface should be or should
> I just take a whack at it and see what people think?
Probably for unambiguous c
On Thu, 3 Jul 2003, Joshua Hoblitt wrote:
> > Well mine currently does that and parses durations...
>
> I already said I'd be happy to use your module for parsing durations if
> you beat me to it.
>
> I set the bar low enough to get something stable for release.
Joshua, why don't you check yours
On Thu, 3 Jul 2003, Flavio S. Glock wrote:
> On Thu, 3 Jul 2003, Flavio Soibelmann Glock wrote:
> > $base_set->{set}{as_ical} = [ uc('recur:'.$recur_str) ];
>
> Dave Rolsky wrote:
> > use a subclass of DateTime::Set.
>
> Ok, I think it might work. How
On Thu, 3 Jul 2003, Jesse Shy wrote:
> Yes, please, tell me what to change. I dont know what it should have been.
> I looked at the date time module and the DateTime-TimeZone modules for
> examples and read the standards from the web site. So I used named
> parameters, did I miss something that s
On Fri, 4 Jul 2003, Joshua Hoblitt wrote:
> > The DT::Set::ICal class is inlined into DT::E::Recurrence.
> > Maybe it should be published separately?
>
> I think so - not everyone that uses DT::E::Recurrence will want it.
So what? It's 69 extra lines, and it doesn't really have much use outside
401 - 500 of 1439 matches
Mail list logo
