Re: Business Dates
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, could grow incrementally, under the discipline of avoiding the creeping redundancy starting to infect the DT project. Yes! I agree 110%. There's way too much discussion in this thread of all the possible possibilities, and not enough of here's the one or two things I have to deal with. Let's worry about the latter for now. As to creeping redundancy, I don't see any big problems with that _yet_, but I am seeing a tendency on lots of people's parts here to want to over-engineer the heck out of everything. A good example was the recent discussion of custom locales, which got way too complicated _before_ any code had even been released! Working, useful code first, then fancy ultra-powerful code. I think the evolution of the DateTime.pm module is a good example. The first version did things _I_ thought were useful. It's grown since then based on feedback from others about the things they needed. For now, I see two really important areas for business that should be addressed. 1. A DT::Business::FiscalYear module, which lets you set an arbitrary date as the first of the year, and do calculations based on that. This would probably be a simple wrapper around DateTime.pm that overrode things like day_of_year, quarter, etc. 2. A DT::Business::Calc module (bad name though) that implemented date math in terms of a DT::Business::Calendar module that defines holidays and such, so that adding 2 days skips weekend, holidays, etc. This might also require something that has been discussed before, but not implemented, which is attached arbitrary extra info to objects in sets so that we can ask if a day is a half or full work day, etc. Implementing both of those, and making sure they work together, would provide some great building blocks for additional functionality, and would satisfy a lot of people. By all means keep discussing other, more complicated or obscure problems, but please don't do only that in favor of coding ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime::Locale - new release for feedback
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 looked at the CVS code. Based off the glacial response I've got from the openI18N guys - yeah, that looks wrong, we'll fix it - now one and a half months later and no change yet - my gut feeling is that the Locale data should go into CVS as it is now. Corrections and additions would then go directly into the DT::Locale CVS rather than waiting weeks for fixes to get put into the ICU locales. But I'm guessing that's not what you have in mind - do you want the DT::Locale code as it stands to go in, or are you only really interested in the conversion script? If it's the latter, I'll try to get it into a maintainable state, but that will take a while longer, no question about that! We can't put the generated code in CVS without the generator. We need to be able to make changes in stuff like Locale.pm without having to email you and ask you to do it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime::Locale - new release for feedback
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? Just release it and I'll clean it up if necessary. I'm not willing to check in generated code without having the generator available, though. If you're really not willing to release yours, I'll just write one from scratch that generates the same output. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] DateTime::Util
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, for %O and %W! So a constructor wouldn't really help in this case. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Rough ISO8601 parser ready...
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 ===*/
DateTime.pm on Win32?
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 Consulting www.houseabsolute.com ===*/
Slides from YAPC presentation
I put these on datetime.perl.org. They're linked from the resources page. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
catching up
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.houseabsolute.com ===*/
DT::F::Epoch
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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: namespaces, command and control (fwd)
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 at YAPC so maybe I can find a [EMAIL PROTECTED] person to prod. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [announce] DateTime::TimeZone::Alias 0.01
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 the value, maybe we
need an alias() method.
(In fact an add(America/New_York should also not die). My theory
being that people may have a sanity check in a few places to make sure
the right TZ mappings are defined. For instance at work we use Mason
running in mod_perl under Apache, so the same environment persists
across different pages. If one page does the add() I wouldn't want a
subsequent page to have to jump through hoops to check the definition
of the alias is correct if doing an equivalent add()... I don't think
we lose anything by allowing a subsequent add() to silently be skipped
if it is the same.
Wouldn't this be something you'd stick in a module anyway?
One last thing, I just realized that the subs expect to be called as
class methods. This is fine unless you want to alias them into your
package (or accidentally call them like DateTime::TimeZone::Alias::add()).
The following fails:
--
use DateTime::TimeZone::Alias;
*set_tz = \DateTime::TimeZone::Alias::set;
set_tz(EST = US/Eastern);
--
sub set_tz { DateTime::Time::Zone::Alias-set(@_) }
-dave
RE: Win32 failures in t/20infinite.t
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 (wstat 65280, 0xff00) DIED. FAILED tests 1-71 Failed 71/71 tests, 0.00% okay Which version of DT::TZ are you using? t\20infinite..NOK 14# Failed test (t\20infinite.t at line 56) # got: '0' # expected: '1.#QNAN' t\20infinite..ok 38/38# Looks like you failed 1 tests of 38. t\20infinite..dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 14 Failed 1/38 tests, 97.37% okay Well, at least this is almost fixed. Wish I knew what the problem was here though. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime modules for Debian Linux
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 or prospective maintainers who would like to take them overi'd be happy to help. I'm actually interested in becoming a Debian developer. Let's meet up at YAPC and discuss it. I need to get my key signed anyway. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Win32 failures in t/20infinite.t
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.#INF
my $nan = $posinf - $posinf;# -1.#IND
(I'm assuming that means INDeterminant), whereas the code
my $dur = $pos - $pos;
yields an object that looks like this:
$dur = bless( {
sign = 0,
nanoseconds = 0,
seconds = 1.#QNAN,
eom_mode = wrap,
minutes = 0,
months = 0,
days = 1.#QNAN
}, 'DateTime::Duration' );
I'm not sure why nanoseconds is 0; if I step through the DT::Duration-new() it
looks exactly like seconds and days.
If you change the third line mentioned above like this:
my $nan = abs($posinf - $posinf); # 1.#QNAN
then the two tests for seconds/days pass, but the nanoseconds fails since it is
0 and not 1.#QNAN as it should be. Still investigating...
Any updates on this? The Win32 problems are the only thing holding me
back from the next release at this point, I think.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: RFC: Adding custom locales to DateTime::Locale part deux
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', 'German_Germany_Ridas custom 1', 'Deutsch_Deutschland_Ridas custom 1'); I think it'd be nice to make these named parameters, since there's lots of them and just looking at them doesn't make it obvious what they are. 3) [Optional] Make your registrations permanent Create DateTime::Locale::CustomInstall.pm, and register your locales in the import() method. These locales will be automatically registered whenever DateTime::Locale is used: Don't worry about doing this right now. For now, people can make their own custom module and load it themselves. Let's see how people end up using these modules before adding too many ways to do the same thing to the code. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Compilation on HPUX, AIX, VMS, etc
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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Compilation on HPUX, AIX, VMS, etc
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 propietary Unix variants, or VMS, QNX, or other weird things like that. Ok, add Solaris to this list. The Perl install on the SF Solaris boxes appears to be broken, because the Perl core header files cause errors when they're loaded. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Compilation on HPUX, AIX, VMS, etc
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 propietary Unix variants, or VMS, QNX, or other weird things like that. Ok, forge the compile farm. Grabbing the prereq Perl modules would be a huge pain since there's no FTP access from the compile farm boxes. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::TimeZone 0.19
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 change. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Win32 failures in t/20infinite.t
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
back from the next release at this point, I think.
I'm sorry, I didn't send you a diff for the change, because I didn't know if you
felt it was appropriate to force a mathematic operation in order to get Win32 to
acknowledge that this is NAN. This change should be harmless elsewhere and
should make Win32 pass:
--- 20infinite.t~ 2003-06-02 14:33:19.0 -0400
+++ 20infinite.t2003-06-13 14:07:43.0 -0400
@@ -10,7 +10,7 @@ my $pos = DateTime::Infinite::Future-ne
my $neg = DateTime::Infinite::Past-new;
my $posinf = 100 ** 100 ** 100;
my $neginf = -1 * $posinf;
-my $nan = $posinf - $posinf;
+my $nan = abs($posinf - $posinf);
# infinite date math
{
Ok, I applied this. Does this mean all tests pass on Win32 now?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Win32 failures in t/20infinite.t
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 /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Converting to DT
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 be pretty much what Date::Parse does ;) I'm assuming here that a DateTime::Format::Common module should only support four digit years. If you need two digit years then use a specific date parser module. Ben, I'd recommend taking a look at this for writing DT::F::Common. A module that parsed Date::Manip stuff would be called DT::F::Complex or something like that. The Date::Parse stuff is much more useful for most people though. In fact, DT::F::Common could probably just wrap around Date::Parse, or alternately, just rip the guts out and stuff it in a new module. The DateTime::Format::Common should be *small and fast*. Just like Date::Parse ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Converting to DT
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 be pretty much what Date::Parse does ;) Parse::Date is limited to dates that Time::Local can handle. (It also uses Time::Zone for named timezones.) Only the str2time function uses T::L. And that's only so it can return an epoch. The strptime function, which does all the work, doesn't need it. I'd say rip the guts out and stuff it in a new module focused on working with DateTime. Drop anything that gets in the way (like Time::Local), two digit years, and perhaps named timezones. Supporting Olson time zones should be too hard, since it's just a string match [a-zA-Z0-9/] at the beginning or end. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Converting to DT
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. Since when? This is perl, version 5.005_03 built for i386-freebsd I went through seven stage of hell trying to get it installed. IIRC I had to hack Time::Local. Can't remember though, all I remember is that it wasn't just a case of perl Makefile.PL, make, make test, make install. Does anyone have a legacy system they can try to install on? 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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Time
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 folks wants to say anything :) I guess I need to understand what it's purpose is. Can you show me some examples of how you'd want to use it? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: milli/micro seconds
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 I want us to be accurate. Dave, can you explain to me again why we need nanosecond (an arbitraty fraction) rather than just using fractional seconds? (not floating, fractional) What we're talking about *is* fractional seconds, why not just call it that? There's no imprecision that doesn't already exist in your computer. If your computer can only handle floats down to 6 decimal places, then you're screwed with any other math anyway! Even if it handles it way down to 100 places, as soon as you ask for 'half the googliseconds' you loose precision. Now you're confusing me! Fractional by itself doesn't mean anything, does it? You can't just the numerator without the denominator. In our case, the denominator is 1,000,000,000 and the numerator is the the value of the nanosecond parameter. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: milli/micro seconds
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{micro} * 1000;
Which is why I wanted to put it in the core. This seems to be a
circular argument. :)
The problem with making it a constructor option is that if a user passes
nanosecond _and_ micro/milli parameters, it's confusing. It's bad enough
that fractional_second and nanosecond are overlapping, and in a really
weird way now that I look more closely!
Ugh, the fractional_second parameter must go. The docs for it are all
wrong, and what it's actually doing is _really_ odd.
Anyway, I _really_ don't like having mututally exclusive, but overlapping,
constructor parameters. This makes for hard-to-read docs. Ideally, each
parameter is unique, and falls into the category of required, has
default, or optional.
I said a _wrapper_ was overkill because you could just as easily write
something like:
micro_as_nano { $_[0] * 1000 }
milli_as_nano { $_[0] * 100 }
and then do:
DateTime-new( ..., nanosecond = milli_as_nano(500) )
Isn't that simpler? Is there any need to wrap all the DateTime
constructors? No, obviously not. It's two one-liner exported functions
that are mere syntactic sugar!
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: namespaces, command and control
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 ===*/
Re: First things first
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}'
Once Dave has approved this patch, or at least the names of the new
methods, I can provide Richard Evans with the convertor file for the
ICU locales and I can prepare the new strptime, removing the
customised strftime (and with object based croak behavior).
Somehow I either didn't notice this or forgot about it. 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.
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 reference to such a thing in
ISO8601.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Converting to DT
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's got plans for a major rewrite. Although we all know how busy he is. He's had those plans for over a year, I think ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: Adding custom locales to DateTime::Locale
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::Locale. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Duration is_positive bug?
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 be not positive,
because sign is zero.
That was an intentional change. Zero isn't positive, is it?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Converting to DT
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 example (I saw this in many presentations ): use POSIX qw( strftime ); my $time = strftime( %Y-%m-%d %H:%M:%S, localtime() ); Of course, if this is _all_ you'll ever need, converting to DT is almost certainly a mistake. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
It could be worse ;)
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://www.onjava.com/pub/a/onjava/2003/06/05/java_calendar.html See, it could be worse ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: First things first
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}'
Once Dave has approved this patch, or at least the names of the new
methods, I can provide Richard Evans with the convertor file for the
ICU locales and I can prepare the new strptime, removing the
customised strftime (and with object based croak behavior).
Somehow I either didn't notice this or forgot about it. 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.
I mean CE, not ACE.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Is there any need to support ISO 639-2 language codes in DT::Locale?
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 without 2 letter codes. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: FAQ cleanup
On Thu, 5 Jun 2003, David Wheeler wrote: On Wednesday, June 4, 2003, at 08:28 PM, Dave Rolsky wrote: 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. Tried Pod::Simple::HTML? We should all nicely ask Sean to get it finished, now that his new book is pretty well done. Yeah, I started palying with that, but it's not easily subclassed. In fact, subclassing it is near impossible. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: FAQ cleanup
On Thu, 5 Jun 2003, David Wheeler wrote: On Thursday, June 5, 2003, at 08:25 AM, Dave Rolsky wrote: Tried Pod::Simple::HTML? We should all nicely ask Sean to get it finished, now that his new book is pretty well done. Yeah, I started palying with that, but it's not easily subclassed. In fact, subclassing it is near impossible. 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 is not. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: What should a business module implement?
On Thu, 5 Jun 2003, Ben Bennett wrote: I intend to make some convenience factories that will make some standard holidays (e.g. US federal holidays, each state's holidays, special bank holidays, etc.), I will worry about that later though. Specific holiday calendars can wait until there's a general API for defining them ;) I'm more concerned with the latter. Creating the former shouldn't be too hard if the API is well made. People will of course be encouraged to release these calendar definition modules to CPAN, but the important part of the core API. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::TZ size
On Fri, 6 Jun 2003, Eugene van der Pijll wrote:
The changes are:
- I moved the _generate_spans_until_match() method (that is included in
perhaps half of all DT::TZ's, and is a largish piece of code) to
TimeZone. This saves about 100kB.
- I changed the format of the dst changes, from
{
'short_name' = 'LMT',
'utc_end' = '57875470828',
'utc_start' = DateTime::TimeZone::NEG_INFINITY,
'local_end' = '57875472000',
'is_dst' = 0,
'offset' = 1172,
'local_start' = DateTime::TimeZone::NEG_INFINITY
},
to
['LMT','57875470828',DateTime::TimeZone::NEG_INFINITY,'57875472000',0,1172,DateTime::TimeZone::NEG_INFINITY]
This may make the generated file more obfuscated, but it does make a
difference of 2Mb. (And I find the new format clearer in a way: it is
easier to get an overview of all the changes.)
This is a good start, but it didn't go far enough ;)
You still have it turning those array refs back to hash refs. Might as
well just go for it and use arrays internally. It's faster and uses less
memory.
Anyway, I think I've got that done.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: ANNOUNCE: Time::Local 1.06
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 patches to p5p real soon now. Too late. Integrated in the core as change #19702, thanks! Cool, that saves me some work. Thanks, -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::TZ size
On Fri, 6 Jun 2003, Eugene van der Pijll wrote: The generated TimeZone modules are a bit larger than they could be. With the attached patch, their total size is reduced by almost 50%. Can you resend this as a unified diff (-u)? I can't read the other kind very easily so I can't actually figure out what this is doing. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime 0.12CVS - Success from Cygwin, still failing under VC++
On Wed, 4 Jun 2003, John Peacock wrote:
The t/13strftime.t file has DOS line endings, which causes all tests to fail
under Cygwin. If that is corrected, then Cygwin tests completely clean.
Really? I can't see them.
However, I am still seeing the following failures with Win32/VC++:
t\04epoch.t 255 65280283 10.71% 26-28
t\20infinite.t3 768363 8.33% 12-14
even after installing the updated Time::Local from CPAN.
Specifically, the first failure is this block:
{
my $dt = DateTime-from_epoch( epoch = -2082844800 ); #fails here
is( $dt-year, 1904, 'year should be 1904' );
is( $dt-month, 1, 'month should be 1904' );
is( $dt-day, 1, 'day should be 1904' );
}
which fails because this code in from_epoch():
@args{ qw( second minute hour day month year ) } =
( gmtime( delete $p{epoch} ) )[ 0..5 ];
does not, in fact initialize anything in the %args hash:
%args = (
month = undef,
day = undef,
minute = undef,
year = undef,
hour = undef,
second = undef
);
Apparently M$loth's implementation of gmtime() doesn't support negative numbers
_at all_:
D:\working\DateTime-0.12perl -e print ''.scalar gmtime(1).''
Thu Jan 1 00:00:01 1970
D:\working\DateTime-0.12perl -e print ''.scalar gmtime(-1).''
even though time_t is defined as a long integer (not unsigned long):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt_mktime.asp
MORONS!
Indeed. I guess I'll just skip those tests on Win32 for now.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Test failures with DateTime from CVS
On Tue, 3 Jun 2003, John Peacock wrote: Is anyone else having massive problems getting cvs.sourceforge.org to behave? I have only once in a bunch of times since yesterday been able to connect and sync my sandbox with the DateTime repository. Most of the time I get: $ cvs upd -Pd cvs [update aborted]: end of file from server (consult above messages if any) but nothing useful (even turning on tracing). SF has a hard limit on the total number of anonymous CVS connections allowed, and this is the symptom. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [Poop-group] Re: ... entering into the fray ...
[ cc'd to datetime list ] On Wed, 4 Jun 2003, Sam Vilain wrote: So, just what are those various optimizations in doing time zone calculations ? OK, building indexes is fine, but can't you access I'm not sure what you're referring to. the majority of the data from the installed Olson Database at run time? I'm not sure they exist on all systems is the main problem. And they're in a binary format that isn't well documented. against the module. I really would like to remove my dependancy on Date::Manip, but, really - 4.5MB? 4.5MB in a time when 80GB disks cost $80! Size is very low on my priority list. Correctness comes first, then ease of use, then speed, then lots of other stuff, then maybe size on disk. Would you prefer if I took this (politely and less ranting, of course) to [EMAIL PROTECTED] Yes, I just cc'd my reply to the list. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Patch DateTime-0.12 on HPUX Perl 5.8.0
On Mon, 2 Jun 2003, Dan Sully wrote: HPUX doesn't have finite() - it has isfinite() instead. Not my HPUX box. I'm running 10.20 and the HP ANSI C compiler I tried the make test and here is a listing of the errors Of course they would have to change it between 10.20 and 11.00/11i I unfortunately don't have a 10.20 box to test on. What does a 'man finite' get you? How about doing this in the source: #ifdef _HPUX_SOURCE # ifdef isfinite #define finite isfinite # endif #endif ?? Does that work? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Changes to latest CVS for infinite bits
I tweaked the code that is looks like this: #include math.h #ifndef isfinite # ifdef finite #define finite isfinite # endif #endif Then later I have #ifdef isfinite void _normalize_seconds(self, days, secs) I'm hoping this can work better for all systems, since there may be systems besides Win32 that don't provide isfinite() in their math.h. If the XS version of _normalize_seconds doesn't get compiled, then the pure Perl version is used, so the code should continue to work, at least. Patches to do more header loading/macro defining/etc to make the XS code work on more systems are welcome, of course. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Time::Local 1.06
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 times during a DST transition. This is from a patch by Dave Mitchell currently in bleadperl. See http://bugs6.perl.org/rt2/Ticket/Display.html?id=19393 for details. Thanks to Rafael Garcia-Suarez for pointing this out to me. - Updated the AUTHORS section to include the actual authors. Thanks to Graham Barr for telling me who there are. - Added SUPPORT section which tells people to use bugs.perl.org or perlbug, since I read p5p and I want to make sure that the core and this code stay in sync. - Clarified docs to say that dates before the system's epoch may or may not work, because POSIX only requires support for positive time_t values. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: What should a business module implement?
On Wed, 4 Jun 2003, Ben Bennett wrote: As a first cut: - Business day arithmetic: - Addition - Subtraction - Differences (how many b. days between X and Y) - Know about holidays Be able to take a set specifying holidays. Attempting to know all possible holidays for all countries/businesses is too hard. - Have settable weekend day(s) - Know about business hours - Way to say if a given DT is during business hours - Way to say if a given DT is a business day Be able to specify a day as a partial day, perhaps. Or maybe that falls under the heading of business hours. Unknown: - Week numbers? This can go in DateTime.pm if it's important. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
FAQ cleanup
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 /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Time::Local 1.05
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 Perl as well, but I don't have anything earlier than 5.00503 installed. Changes made from the core version include: - Packaged for distribution on CPAN. - Added an AUTHOR section to the docs. - Clarified some points in the docs, particularly the fact that this module uses the local system's epoch, not the Unix epoch, contrary to what the documentation suggests. - Disabled tests for timelocal.pl Perl4 library since it's not included in standalone distribution. I'll send patches for the core once a few people confirm that I didn't screw anything up. If DateTime list folks who were seeing t/04epoch.t failures with the CVS DateTime.pm could install this and try again, that'd be helpful. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: installing DateTime-TimeZone-0.17 on HPUX 10.20... or Cygwin
On Mon, 2 Jun 2003, Ben Bennett wrote: I still think it is a MakeMaker problem, has anyone reported it to them? And are you guys using the latest MakeMaker? I think this might have been fixed in the new beta versions. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: FAQ
On Mon, 2 Jun 2003, Flavio S. Glock wrote: FAQ said: 2.3: Why do I need to truncate dates? ... Of course if you are trying to work out if an hour long meeting is going on now then you should truncate to hours... but for that kind of thing you probably want a DateTime::Span RFC - Do we need something like this? $span = DateTime::Span-hour( $dt ); $span = DateTime::Span-day( $dt ); ... What does this do? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: FAQ
On Mon, 2 Jun 2003, Flavio S. Glock wrote: Dave Rolsky wrote: On Mon, 2 Jun 2003, Flavio S. Glock wrote: RFC - Do we need something like this? $span = DateTime::Span-hour( $dt ); $span = DateTime::Span-day( $dt ); ... What does this do? It is a shortcut to build frequently-used spans: $dt = DateTime-new( year = 2003, month = 10, day = 5, hour = 11 ); $span = DateTime::Span-day( $dt ); # whole-day span: # [ 2003-10-05T00:00:00 .. 2003-10-05T23:59:59 ] this is a tipical application: $set = DT::E::Recurrence-xxx; $today_events = $set-as_list( span = DateTime::Span-day( today ) ); $month_events = $set-as_list( span = DateTime::Span-month( today ) ); I don't think month makes it clear that it's this month versus the date and one month after it. I'm not averse to shortcuts, but they need to have clearer names. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: Windows once more
On Mon, 2 Jun 2003, Hill, Ronald wrote: I was not able to find the Time::Local module on CPAN Yeah, it's not there yet. t\20infinite..NOK 12# Failed test (t\20infinite.t at line 55) # got: '1.#QNAN' # expected: '-1.#IND' t\20infinite..NOK 13# Failed test (t\20infinite.t at line 55) # got: '1.#QNAN' # expected: '-1.#IND' t\20infinite..NOK 14# Failed test (t\20infinite.t at line 55) # got: '0' # expected: '-1.#IND' t\20infinite..ok 36/36# Looks like you failed 3 tests of 36. ARGH! I give up. Someone else is going to have to fix this on Windows at this point, or maybe I'll just disable these tests on Win32. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: Windows once more
On Mon, 2 Jun 2003, Hill, Ronald wrote: ARGH! I give up. Someone else is going to have to fix this on Windows at this point, or maybe I'll just disable these tests on Win32. -dave Oh, Dave please don't give up. We need this for all Platforms Otherwise, modules that use recurences will fail horribly! (like mine). This is the reason I need to install the latest DateTime.pm module, So I can test my module. I give up in the sense of patches welcome, but I don't have any idea what the problem is, so it's going to take someone who actually understands Windows to fix this. I can't even get it to work on HPUX :( Try removing the ifdef _HPUX_SOURCE part entirely. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: FAQ outstanding questions...
On Mon, 2 Jun 2003, Ben Bennett wrote: 2) What is the overlap between DateTime::Format::Builder and DateTime::Format::Strptime? Which is preferred? Yeah, I'd like to know too. 4) Wasn't this [the DateTime constructor croaking on bad dates] going to be overridable? Not unless someone shows me a use case for it that can't be easily solved some other way. 6) Is there something equivalent for two days from the end of the month? Should there be? Perhaps the flag should say whether the start or end of the month offset is what matters... [In DateTime::Duration] my $dt = DateTime-last_day_of_month( year = 1999, month = 2 )-subtract( days = 2 ); 7) Do Sets constructed from explicit dates always get sorted? This question doesn't make sense. Sets are explicitly not an ordered entity. You're thinking of lists, which a set can be turned into. 8) Should DateTime::Set have a way to add an more explicit dates without having to make a new set and union it in? You can do $set-union($dt_object). I suppose allowing multiple arguments would make sense too. 9) Do we need a DateTime::Set clone method (ditto span, etc.)? It doesn't hurt. 10) Did we ever work out how to attatch information to a date from a set? [I remember a proposal floating about, I will have to look at the archives] No, I think this needs to be some sort of DT::Set extension. 11) Are we going to return an object for +/-inf or will it always be a string? [I remember some discussion here, how did it turn out?] It's not a string right now, it's a number that stringifies in various ways. Returning an object might be better. 13) How do I set a time zone on a set? (and span and spanset) You can't. That doesn't make sense. Set it on the objects you feed into it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: Object::Stringify
On Fri, 30 May 2003, Ben Bennett wrote: This class allows you to wrap an arbitrary object and provide stringification and numification methods while changing the interface to the object as little as possible. Have you taken a look at Class::Decorator on CPAN? What you've implemented is more or less the decoration pattern, but specifically oriented at overloading. I'd suggest either offering a patch to Class::Decorator to allow for overloading or to implement a Class::Decorator::Overload module that uses Class::Decorator and adds overloading, if the author doesn't accept your patch. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Rough first draft of a FAQ
On Fri, 30 May 2003, Ben Bennett wrote: On Fri, May 30, 2003 at 12:36:17PM -0500, Dave Rolsky wrote: The archives are linked on the mailing list page and the modules page has links to each module's CPAN page. OK. At the very least I want to leave a link to the top of datetime.perl.org in case they came in using a link fron elsewhere (e.g. google). Well, my plan was to integrate it into the site directly, so that the look and feel is the same, and the left menu is still present. I will probably leave the tip for how to search the archives with google unless you are strongly opposed. That's fine. How do you want to progress from here... I will try and get the TODO items cleaned up and have a look at the grouping and ordering. At some point I should get CVS access and commit the stuff. I can give you CVS access now and you can stick it under a top-level FAQ directory. Email me your sourceforge username. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Windows once more
Ok, I think the test results for 20infinite.t may be different because of recent changes in subtract_datetime. Could a Windows user run the tests again, please? For the 04epoch.t failures, I think I'll need to be able to use the latest Time::Local code, which means releasing it to CPAN. Hopefully this will happen soon. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Cleaning up Locale modules by using if.pm
On Sat, 31 May 2003, Richard Evans wrote:
No need to use if.pm really. Just do this:
BEGIN {
eval 'use utf8' if $] = 5.006;
}
Yeah, I thought that should work, but I knocked up a quick test:
BEGIN
{
eval 'use warnings' if $] = 5.006;
}
use if $] = 5.006, warnings;
print Unitialised: , $a, \n;
If I comment out the 'use if' line, I don't get the expected Use of
uninitialized value in print warning, so I'm guessing the eval won't work
for the utf8 pragma either (scoping issue?).
Yeah, it might be scoping. Easy enough to test. Just do:
{
use warnings;
}
print uninit , $a, \n;
And indeed, no warning. Guess you have to use if.pm. I wish it had a
less ridiculous version number. I guarantee someone will balk at
installing it because the version number is too low or something dumb
like that. At least it comes with 5.8.0.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DT::F::Builder strptime test fails
On Sun, 1 Jun 2003, Rick Measham wrote: At 5:03 PM -0500 31/5/03, Dave Rolsky wrote: But then I went to install the latest DT::F::Strptime and it failed too! Patches for the latter may be forthcoming. At 5:07 PM -0500 31/5/03, Dave Rolsky wrote: Looking through the DT::F::Strptime code I see variables named $olsen and such. Just to clear this up for anyone who wants to refer to this in their code or docs, the man's name is Arthur David _Olson_. Credit where it's due and all ;) Does the latter mean that you are working on patches? If so, are you changing the carp behaviour as discussed earlier in the week or are you working on other things? Let me know so we don't overlap. Nah, I gave up on patches because I realized _you_ need to send _me_ patches! Here's what I think we need to do: - get rid of strftime in DT::F::Strptime and integrate its extra functionality into DT.pm proper, as was discussed before. You should do this. - add a method for constructing an object based on year and day of year, so DT::F::Strptime stops trying to do DateTime-new( year = 1, day = 275 ) which is what causes the tests to fail. This one I can do easily enough. For the croak stuff, I'm sure you can fix it, and the olsen = olson thing's just a search and replace. How's that for a plan? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: Bug in DateTime::Span-contains()
On Fri, 30 May 2003, Hill, Ronald wrote: Great!! At least that tells me the bug in my module is fixed :) Are you using DateTime-Set version 0.07 and DateTime 0.12? (I need to update the pre req's for sunrise) I wish we could get the DateTime.pm to work on windows. Have you tried the latest CVS version? It's getting closer, I just need some help debugging the problems. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [PATCH] DT::Language alternate namespaces
On Thu, 29 May 2003, Joshua Hoblitt wrote: Uh, they could just call it DT::Language::MyLanguage, right? Do we really want people including DT::Language::* modules in there distributions? If it was something like DT::Language::Custom::Foo, I probably wouldn't care. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: installing DateTime-TimeZone-0.17 on HPUX 10.20 perl 5.8.0 using HP's ANSI C Compiler?
On Fri, 30 May 2003, Hill, Ronald wrote: Hi All, Has anyone installed DateTime-TimeZone-0.17 on HPUX? make is reporting line to long. $ /app/perl5.8.0/bin/perl Makefile.PL Writing Makefile for DateTime::TimeZone $ make Make: line too long. Stop. $ which make /bin/make $ ls -l /bin/make lr-xr-xr-t 1 root sys 17 Nov 1 1999 /bin/make - /usr/ccs/bin/make I have checked the Makefile.PL file for those ^M char and found none. Does anyone have any ideas? This might be fixed by upgrading ExtUtils::MakeMaker to a newer version. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Rough first draft of a FAQ
On Fri, 30 May 2003, Dan Sully wrote: * Ben Bennett [EMAIL PROTECTED] shaped the electrons to say... I have a (very) rough draft of a faq available at: http://www.limey.net/~fiji/perl/ Ben - I like the FAQ a lot. A suggestion though - you offer quite a few functions that do useful things, ie: get_day_in_same_week, etc. It'd be useful (to me at least) if those made it into a DateTime::Helpers or somesuch. Or maybe just into the core. I'm open to adding more methods, as long as they provide something useful that people would otherwise end up re-implementing in their own code. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: installing DateTime-TimeZone-0.17 on HPUX 10.20 perl 5.8.0 us ing HP's ANSI C Compiler?
On Fri, 30 May 2003, Hill, Ronald wrote: Has anyone installed DateTime-TimeZone-0.17 on HPUX? make is reporting line to long. $ /app/perl5.8.0/bin/perl Makefile.PL Writing Makefile for DateTime::TimeZone $ make Make: line too long. Stop. This might be fixed by upgrading ExtUtils::MakeMaker to a newer version. I have upgraded MakeMaker to the current version still fails with line to long :( I doubt ther's much I can do about it, since I don't think changing the module names just for this is a good idea. Presumably, the long module name plus your path is too long. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [PATCH] DT::Language alternate namespaces
On Thu, 29 May 2003, Joshua Hoblitt wrote: Here is a small patch to allow arbitrary namespaces to be passed to DT::Language. This is useful for modules that want to include their own DT::Language subclasses or want to generate information at runtime. Uh, they could just call it DT::Language::MyLanguage, right? Anyway, I want DT::Language to go away soon in favor of DT::Locale. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DateTime::Span-contains()
On Thu, 29 May 2003, Ben Bennett wrote:
Actually there are two bugs (yes my sandbox is current).
The first is fixed by the patch below (it creates an unused $tmp
DateTime::Span object without the required args).
The second is more tricky... DT::Span tries to create a DT::Set
object, but doesn't use DT::Set. This is nasty to fix since DT::Set
uses DT::Span, so you don't want to make a circular dependency. I am
not sure how best to fix this.
There's no such thing as a circular dependency in Perl. Two modules can
use each other.
A script to catch this is:
---
use DateTime;
use DateTime::Span;
my $low_date = DateTime-new(year = 2002, month = 3, day = 1);
my $high_date = DateTime-new(year = 2002, month = 2, day = 11);
my $test_date = DateTime-new(year = 2002, month = 2, day = 23);
# Make sure the high is higher than the low
($low_date, $high_date) = ($high_date, $low_date)
if $low_date $high_date;
# Make the span (note that we don't need to flip the dates)
my $span = DateTime::Span-from_datetimes(start = $low_date,
end = $high_date);
if ($span-contains($test_date)) {
print '$test_date is between the given dates';
}
I fixed this.
Index: lib/DateTime/Span.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-Set/lib/DateTime/Span.pm,v
retrieving revision 1.20
diff -u -r1.20 Span.pm
--- lib/DateTime/Span.pm8 May 2003 00:35:32 - 1.20
+++ lib/DateTime/Span.pm30 May 2003 02:36:20 -
@@ -159,7 +159,7 @@
sub intersects {
my ($set1, $set2) = @_;
my $class = ref($set1);
-my $tmp = $class-new();
+my $tmp = {}; # $class-new();
$set2 = DateTime::Set-new( dates = [ $set2 ] ) unless $set2-can( 'union' );
return $set1-{set}-intersects( $set2-{set} );
}
@@ -167,7 +167,7 @@
sub contains {
my ($set1, $set2) = @_;
my $class = ref($set1);
-my $tmp = $class-new();
+my $tmp = {}; # $class-new();
$set2 = DateTime::Set-new( dates = [ $set2 ] ) unless $set2-can( 'union' );
return $set1-{set}-contains( $set2-{set} );
}
You'll note $tmp was not used at all. I removed it.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Rough first draft of a FAQ
On Fri, 30 May 2003, Ben Bennett wrote: The general structure of the page is quite likely to change (as are the question numbers). I plan on adding more sections and reordering the existing questions, but I wanted to get feedback first. It generally looks great. If people could propose additional questions for the FAQ (if you provide answers that would be even better), provide code suggestions and answer any QUESTIONs I have that would be fantastic. First I'll pick some nits. - Assume it will be hosted on datetime.perl.org, so you can skip the first 4 questions. - Please don't use fixed number offsets for the time zone examples. This only encourages broken code when people do this in real apps when instead they should use a named time zone. Now to answer specific questions: 2.3: Why do I need to truncate dates? QUESTION Is it worthwhile to add an optional resolution argument to compare to allow easier usage? Maybe. My theory is that most people will take advantage of overloading and just use Perl's built-in comparison operators. 2.4: What is the floating time zone? QUESTION Should compare_ignore_floating take an optional timezone argument? (See also the possible argument for resolution...) I think the section of the floating time zone should have a big fat warning that mixing floating time zones and real time zones is likely to lead to a mess. The floating time zone option exists for people who want to abstract datetime stuff. Mixing it with actual time zones, unless you really understand why you're doing so, is bound to lead to trouble. All of which doesn't answer your question, but the point is I don't want to make mixing floating non-floating so easy that people don't think twice before doing so. 2.21: How can I calculate the last business day (payday!) of a month? QUESTION: Do we do anything with business logic? No, I'm waiting for someone to writing a DateTime::Business module. Any takers? 2.27: How can I calculate the difference in days between dates, but without counting Saturdays and Sundays? QUESTION: Is the best way to do this simply to make a DateTime::Set and loop over it? See above ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: olson data availability?
On Sat, 12 Apr 2003, Matt Sisk wrote: The docs say go here: ftp://elsie.nci.nih.gov/pub/ But it has been inaccessible over the last few days. I can't build the DateTime suite properly! Hmm, worked for me. And of course, if you install DateTime::TimeZone from CPAN there's no need to get the Olson DB. Is there a workaround besides editing Makefile.PL? Will the availability of the Olson archive always be in the critical path of DateTime installation? It's not in the critical path of installation. To be clear, I certainly think having up-to-date info from the Olson db is a good idea, but I'm not sure how I feel about the installation process not having a nice workaround for when we are forced to retrieve the Olson data at a later date. Well, my plan is to release new versions of DateTime::TimeZone whenever there's an Olson DB update. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: leap seconds
On Sat, 12 Apr 2003 [EMAIL PROTECTED] wrote: May I import Date::Leapsecond into modules/DateTime.pm/lib/DateTime/Leapsecond.pm? I could then make the changes in DateTime to use it. How will it be used? I've been trying to think of a good way to handle leapseconds in DateTime.pm for a while and I still haven't come up with anything that I'm happy with. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Time::Local (was: Bundle::DateTime)
On Fri, 4 Apr 2003, Iain 'Spoon' Truskett wrote: Are there details of how MakeMaker and CPAN.pm treat 0 and undef in prereqs? It's treated as any version. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::Event::Basic
On Thu, 3 Apr 2003, Flavio S. Glock wrote:
Flavio S. Glock wrote:
DateTime::Event::Basic - A base class for building Event classes.
Ok, I think I'll explain this a bit more:
For example, DateTime::Event::Sunset would be simplified to:
@ISA = qw( DateTime::Event::Basic );
sub initialize {
[snipped param checking]
$self-{event_name} = $parm{event};
$self-{logitude} = $parm{longitude};
$self-{latitude} = $parm{latitude};
$self-{next} = \_next_sunrise if $self-{event_name} eq 'sunrise';
$self-{next} = \_next_sunset if $self-{event_name} eq 'sunset';
$self-SUPER::initialize;
}
I think the problem is that this (AFAICT) forces all events to be dealt
with as sets internally, which may not be what many module authors want to
do.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Bug in epoch handling [patch]
On Tue, 1 Apr 2003, Iain 'Spoon' Truskett wrote: * Iain 'Spoon' Truskett ([EMAIL PROTECTED]) [01 Apr 2003 13:18]: Adding and subtracting small durations doesn't appear to affect the epoch. I tried adding a line to recalculate it, but that just seemed to screw things up elsewhere. Ok. After having a break for lunch and doing some other stuff: This probably isn't perfect; I've not really examined how the internals of DT.pm operate. On the other hand, it does still pass all tests =) I fixed this a slightly differnet way, but the tests were helpful. Thanks, -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Announce: DateTime-Format-Builder 0.25
On Mon, 31 Mar 2003, Joshua Hoblitt wrote: I started implementing all of ISO8601:2000 last night with Builder.pm. After looking at the pod for awhile I started thinking that this could be simplified [and optimized] a little if you don't mind dirtying the namespace. Some POEish like this: my ($date, $p) = @_[ INPUT, PARSED ]; Ugh, this is _so_ ugly, and it's a really silly micro-optimization. In most normal code, you spend most of your time doing stuff, not passing arguments, so optimizing argument passing is generally not going to be much of a win. And it's certainly not worth it when it forces such weird non-standard internals. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::Format::ICal 0.03
0.03 2003-04-05 - Handle offset-only time zones without producing garbage output. Bug report from Iain Truskett. - Switch to Module::Build. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime 0.09
No particular reason for this release, just an accumulation of improvements and fixes. 0.09 2003-04-05 (the liberation through violence release) [IMPROVEMENTS] - As requested by numerous people, there is now a pure Perl implementation of DateTime.pm included with this distribution. If you don't have a C compiler it will be used instead of the XS implementation. - Document how floating time zones are handling in comparisons, and add the compare_ignore_floating method. Based on a patch from Eugene van der Pijll. - Allow from_epoch(), now(), and today() to accept a time_zone parameter. Based on suggestions from Tim Bunce and Joshua Hoblitt. - Allow extraction of AM/PM string list from DateTime::Language classes. - Added quarter() and day_of_quarter() methods. Based on a patch from Tim Allwine. [BUG FIXES] - If a datetime had the floating timezone and then set_time_zone was used to set it to something else, the internal UTC time of the object was not changed, meaning that its offset could be calculated incorrectly. Patch by Eugene van der Pijll. - If datetime math was done with hours, minutes, or seconds, the return value of -epoch would be wrong after this. Based on report and patch from Iain Truskett. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Duration compare
On Fri, 4 Apr 2003 [EMAIL PROTECTED] wrote: I noticed DateTime::Duration = is not checking the 'reverse' flag. Also, it would be useful to be able to compare a duration to zero, in order to check if it is negative, positive or null. I could do that, just tell me if it is ok. Sounds fine to me. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Duration compare
On Fri, 4 Apr 2003 [EMAIL PROTECTED] wrote: I noticed DateTime::Duration = is not checking the 'reverse' flag. Also, it would be useful to be able to compare a duration to zero, in order to check if it is negative, positive or null. I could do that, just tell me if it is ok. Actually, come to think of it, if you look at the DateTime.pm TODO, it mentions overloading multipication and division as well, if you're into it ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Duration compare
On Fri, 4 Apr 2003, Dave Rolsky wrote: Also, it would be useful to be able to compare a duration to zero, in order to check if it is negative, positive or null. Ugh, I must take a moment before replying to mail. I thought about this a bit more and realized I don't really like it, because it special cases one number, zero. But comparing it to other numbers wouldn't make sense. I really don't like strange special cases, and it's likely to lead to incorrect usage, which will lead to fatal errors, which will lead to confusion. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Updated DateTime::Calendar dev docs
I've updated the docs on developing a DateTime::Calendar module to reflect recent discussion of time zones, calendar without a time component, and some other API stuff I wanted to include. Please take a look. Questions and suggestions are welcome. http://datetime.perl.org/developer/calendar.html -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Wed, 2 Apr 2003, Joshua Hoblitt wrote: - should it have a clone method? Only if it has methods that can change the internal object state after it's created, like DateTime.pm's set(), set_time_zone(), etc. - when from_object is used should the value for seconds returned by utc_rd_values be stored then returned by the object itself? This would allow chaining of calendars without a loss of precision. Yes, please do so. I will add this to the calendar development docs. - what other methods would be useful? Offhand, -set(), -add(), -subtract(), accessors for each component (baktun, katun, etc.) - can I have some suggestions for tests? The tests you have so far look fine. As you add more methods, add more tests ;) Why does from_object take a language parameter? Cut and paste-o? It's not being used internally. Also, according to Abigail's Data::Maya module, there are three possible Mayan epochs. Maybe this should be changeable on a per-object basis. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, 3 Apr 2003, Joshua Hoblitt wrote: Actually, I'm starting to think that it might be better instead to simply have a local_rd_values method and use that instead, maybe. Or barf on floating times. Or document it. In practice, I think _most_ people working with multiple calendar systems will not even care about the time component, and will be doing stuff like: my $date = DateTime-new( year = 1900, month = 7, day = 6 ); my $mayan = DateTime::Calendar::Mayan-from_object( object = $date ); # display mayan date $mayan-add( baktuns = 2 ); my $new_date = DateTime-from_object( object = $mayan ); # display Gregorian date In this case, since floating has the same utc_rd_values as local_rd_values, everything works just fine. I think trying to impose modern time systems on ancient calendar is not very feasible. So the million dollar question is should DT::C::Mayan support timezones? Or is UTC the right thing to do? I'd say supporting time zones in other calendars is probably not worth the effort, even if we could agree on what correct support would look like ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, 3 Apr 2003, Eugene van der Pijll wrote: And this works. But even more people will use DateTime-now. And then a floating time would be wrong. Why would a floating time be wrong then? As an example, the first program I wrote using DateTime::Calendar::Mayan. use DateTime; my $d = DateTime-now; $d-set_time_zone( 'Europe/Amsterdam' ); $d-set_time_zone( 'floating' ); print $d-strftime(%A %d %B %Y\n); use DateTime::Calendar::Julian; $d = DateTime::Calendar::Julian-from_object( object = $d ); print $d-strftime(%A %d %B %Y Julian\n); use DateTime::Calendar::Pataphysical; $d = DateTime::Calendar::Pataphysical-from_object( object = $d ); print ucfirst $d-strftime(%A %d %B %Y [%*]\n); use DateTime::Calendar::Mayan; $d = DateTime::Calendar::Mayan-from_object( object = $d ); print $d-date, \n; Can you show the output and explain the problems? Honestly, I have no clue what this _should_ print. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE] DateTime-Calendar-Japanese 0.01 and DateTime-Format-Japanese 0.01
On Tue, 1 Apr 2003, Daisuke Maki wrote: I've hacked together DT::Calendar::Japanese and DT::Format::Japanese. Is there anybody on this list that can use Japanese on his machine? I somehow got emacs to do so, yes. If it's working and displaying the right characters, then my pathetic character reading skills tell me that the era beginning 857 2 21 was the heaven peace era, or something along those lines. Pls let me know if I did anything glaringly wrong. Well, what you made works, but I think it's somewhat missing the point. Your module simply takes a Gregorian date and then calculates the corresponding Japanese era for that Gregorian date. But your object does not actually represent the Japanese calendar. What I'm getting at is that given a DateTime::Calendar::Japanese object, I'd expect a method like -year to return the year as it is numbered in the _Japanese_ calendar, not in the Gregorian calendar! If I want to know the corresponding Gregorian year, I can always use DateTime-from_object to produce the equivalent Gregorian object. If you take a look at DT::Calendar::Julian, you'll see that if you call -year, you are getting the Julian year, not the corresponding Gregorian year. The same goes for all of its other methods. This is how the DT::Calendar::Japanese class should work. In addition, you'll also want methods like -era, -regime, possibly -kigen, and methods to return the major and minor solar terms. If you do want to do this, let's collaborate, because I want to create DateTime::Calendar::Chinese, and they share a lot of core calculations. We might be able to put these in some sort of DateTime::Algorithm::ChineseJapanese module that we could both include as a prereq. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE] DateTime-Calendar-Japanese 0.01 and DateTime-Format-Japanese 0.01
On Tue, 1 Apr 2003, Daisuke Maki wrote: DT::Format::Japanese: - support kanji, zenkaku arabic, and ascii arabic numbers - support eras BTW, this one looks great. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime and Holidays
On Tue, 1 Apr 2003, Flavio S. Glock wrote: DateTime::Event::Bundle :) I think the DateTime::EventSet name looks too much like DateTime::SpanSet, and this is confusing. And too much like DateTime::Set as well. I don't like Bundle, cause that really confuses things with Bundle:: modules. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime and Holidays
On Tue, 1 Apr 2003, Joshua Hoblitt wrote: In Hawaii we have several extra state holidays that are observed: March, 26 - Prince Jonah Kuhio Kalanianaole Day June, 11 - King Kamehameha I Day August, 15 - Statehood Day What name space should those live under? Should they even be a set? DateTime::(EventSet|Library|Thing)::HawaiiStateHoldays or something to that effect. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime and Holidays
On Tue, 1 Apr 2003, Flavio S. Glock wrote: In Hawaii we have several extra state holidays that are observed: March, 26 - Prince Jonah Kuhio Kalanianaole Day June, 11 - King Kamehameha I Day August, 15 - Statehood Day What name space should those live under? Should they even be a set? It looks like a work for DateTime::Event::Builder Well, whether or not there is such a thing, we still want a namespace for modules which define related groups of holidays. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime and Holidays
On Wed, 2 Apr 2003, Rick Measham wrote: I'm thinking maybe DateTime::Event::PublicHoliday which would load (upon request) DateTime::Event::PublicHoliday::[Region Name] The coding for it would be exactly the same as my current ::Event::Christian module. (Although maybe Australia is the only country where public holidays get bumped so they don't fall on a weekend!) In the US, some (like MLK's birthday) do, and some don't, like July 4th ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Renamed: DateTime::Event::PublicHoliday
On Wed, 2 Apr 2003, Rick Measham wrote: 1. I'll have all the code needed for this in DateTime::Event::Christian 2. You want to be able to load multiple data files but have them all available through the same interface. For example my next-door-neighbour is of Greek descent. He celebrates both Australian and Greek holidays. Sure that's probably not all that common, but it's worth thinking about. No, actually, this will be real common. Think of a Church that honors both state and religious holidays for its employees. One big use of DateTime::Set (I hope) will be creating sets of holidays for internal use at companies so business day calculations can be done properly. These sets will include modules from CPAN (for state holidays), internals stuff (company founder's day) and may sometimes need to import other things like _other_ state's holidays, for example when calculating something related to multiple branches, or when doing business with other companies. The code for DateTime::Event::Christian is almost done so if people want to hold off for a few days, I'll show you how easy it is to turn it into ::PublicHoliday How about show me an API ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC DateTime::Calendar::French_Rev
On Wed, 2 Apr 2003, Jean Forget wrote: As I told long ago (January 2003), the French Revolutionary calendar included a reform to decimalize time counting, with 10 hours per day, 100 minutes per hour and 100 seconds per minute. But this reform was never put into effect. So, my module should give access to both sexagesimal time (historically correct) and decimal time (interesting and fun). For the moment, there are two sets of accessors: - hour, min, second, etc for sexagesimal time - dhour, dmin and dsecond for decimal time but strftime knows only decimal time. Another way would be to use only one set of accessors, plus a method choose_time_counting or two opposite methods choose_decimal_time choose_sexagesimal_time and all methods: hour, minute, second, strftime would obey the last setting. The default for hour, minute, second, and such should be decimal, because that's what the system used natively. I don't know that it's worth offering sexagesimal time, since people can always use DateTime-from_object to get that. Another question: the 7-day weeks were replaced by 10-day décades. Should I keep the week_number, week_year etc methods, which are inaccurately named, or should I use decade_number, decade_year which might confuse English speakers (because in English, the same word means 10 years)? Or should I propose both? There is absolutely no reason you should feel compelled to offer the full DateTime.pm interface. Offer what makes sense for _your_ calendar. The Julian calendar is actually a really _bad_ example for other calendar module authors, because it's API is almost identical to the Gregorian calendar (DateTime.pm). Most other calendars will have a greater departure from the DateTime.pm API. Lastly, in accordance to CPAN rules, I should ask your advice about naming my module. But http://datetime.perl.org/developer/calendar.html makes it crystal-clear: it should be named DateTime::Calendar::French_Rev.pm If you still have any remarks about this... Can you call it DateTime::Calendar::FrenchRevolution (or FrenchRevolutionary)? I can't stand underscores in module names and I'm not a big fan of abbreviations (that's discussed a bit in the development standards doc). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::extend()
On Mon, 31 Mar 2003, Flavio S. Glock wrote: In module: DateTime New method: extend() Returns a DateTime::Span after the current date. If the parameter is a date, returns the span between the two dates. If the parameter is a duration, returns the span between the current date and date+duration. $dt_span = $dt_start-extend( until = $dt_end ); $dt_span = $dt_start-extend( duration = $dt_duration ); $dt_span = $dt_start-extend( hours = 24 ); Other names: span() to_span() Implementation: calls DateTime::Span-new() auto-uses DateTime::Span I agree with Eugene. This belongs in DateTime::Span, because it's a span constructor. Also, I'm pretty against most auto-use type stuff, because it's not very memory friendly under mod_perl, and I do a lot of mod_perl work. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DST Problem
On Sun, 30 Mar 2003, Richard Smith wrote: I'm having some issues with DateTime and DateTime::Timezone. When creating a timezone object with the timezone of Europe/London it doesn't seem to think we're in DST, but we are, as of 1am this morning. Anything else I've tried to do with it seems fine (the offsets are correct for each zone), but that's throwing all my stuff out by and hour (I'm just called is_dst to check whether we are or not and it's returning 0). What versions of each module are you using? I can't reproduce this problem. Also, if you're using the latest versions of the modules, can you provide a short test script to demonstrate the problem? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DST Problem (not an answer)
On Tue, 1 Apr 2003, Rick Measham wrote: At 9:36 PM +0100 30/3/03, Richard Smith wrote: I'm having some issues with DateTime and DateTime::Timezone. When creating a timezone object with the timezone of Europe/London it doesn't seem to think we're in DST, but we are, as of 1am this morning. Anything else I've tried to do with it seems fine (the offsets are correct for each zone), but that's throwing all my stuff out by and hour (I'm just called is_dst to check whether we are or not and it's returning 0). This makes me think .. should there be a way to 'force' a DST change? For example: $dst_on = DateTime-new([1am this morning]); $dt = DateTime-new(year=, month=xx, day=xx, timezone='Europe/London', dst_on=$dst_on, dst_off=$dst_off); This is much more complicated than you think, and the API would be nasty. I don't think it's worth the trouble. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Language
On Mon, 31 Mar 2003 [EMAIL PROTECTED] wrote: I suspect that same goes for some Asian languages. by the way, I think that the languages we have are using latin1. Maybe we should make it UTF8. Yes, we should, since that's the future of Perl. But then we'd have to provide a bytes version for Perl 5.00503. We already have that in several of the new language modules provided by Daniel Yacob, such as Amharic. It's a bit ugly. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Language
On Tue, 1 Apr 2003, Rick Measham wrote:
sub format_datetime {
$dt = shift;
return sprintf(%s%s%s%s%s%s %s%s%s%s%s%s,
japanese_number($dt-year),
'japanese_for_year',
japanese_number($dt-month),
'japanese_for_month',
japanese_number($dt-day),
'japanese_for_day',
japanese_number($dt-hour),
'japanese_for_hour',
japanese_number($dt-minute),
'japanese_for_minute',
japanese_number($dt-second),
'japanese_for_second',
);
}
Basically, my reason for thinking this is a ::format rather than a
::language issue is that there are very few instances where the
representations of numerals is not the hindu-arabic forms. To put numerals
into ::Language modules would mean the overhead of 'translating' each
numeral whenever its output.
In fact, the Japanese (and Chinese) very often do use Arabic numerals.
There are _also_ characters for numbers which are sometimes used.
What Daisuke (that's your personal name, right?) is suggesting is a way to
display a date and time with Arabic numerals followed by the characters
saying what those numerals mean, if I'm following correctly.
However, it might be good to have a method in DateTime::Format::Japanese
that returns the character representation of the Arabic numerals as well.
Then of course, I start wondering if we couldn't share this with the
Chinese language formatter. And in fact, I suspect that the Japanese and
Chinese date formats would be identical.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: FAIL DateTime-Event-Easter-1.0 i586-linux 2.2.16c32_iii
On Tue, 1 Apr 2003, Rick Measham wrote: DateTime::Event::Easter doesn't use DateTime::Calendar::Julian unless you ask for Eastern (Orthodox) Easter. However one of the test suites requires it to test Eastern known Easters (t/07eastknown.t). Should I: 1) Force everyone to have ::Julian even if they aren't going to use Orthodox Easter? Yes. This should probably be a module prereq since otherwise major functionality isn't available. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::SpanSet new()
On Mon, 31 Mar 2003 [EMAIL PROTECTED] wrote:
RFC: how to name these parameters to the
DateTime::SpanSet-new() method:
#1 - Building a SpanSet from
2 recurrence callbacks:
$set = new DateTime::SpanSet (
starting_recurrence_sub = sub { .. },
ending_recurrence_sub = sub { .. },
);
#2 - Building a SpanSet from
2 DateTime::Set recurrences:
$set = new DateTime::SpanSet (
starting_recurrence_set = $dt_set_start,
ending_recurrence_set = $dt_set_end,
);
Looking at this makes me think that instead, there should be multiple
methods, so we'd have:
DateTime::SpanSet-from_recurrences( recurrences = [ \r1, \r2 ] );
DateTime::SpanSet-from_sets( sets = [ \s1, \s2 ] );
What do others think?
If we go this way, I'd like to see something similar for DateTime::Set, so
we could have DateTime::Set-from_recurrence and DateTime::Set-from_dates
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
