Or use DateTime::TimeZone::Alias [1]
(untested code follows)
use DateTime::TimeZone::Alias
for my $hr in (0 .. 12) {
DateTime::TimeZone::Alias-set(Etc/GMT+$hr, -${hr}:00);
DateTime::TimeZone::Alias-set(Etc/GMT-$hr, +${hr}:00);
}
# And don't forget the 15 minute offsets and the 30
And to ask a nasty question... will it support localization?
Or I suppose if your mapping is from lat/long to TZ then the
localization problem will be in the code for taking a location name
and producing the lat/long. Which makes this more tractable.
-ben
On Sun, Mar 28, 2004 at
Of course the overloaded stringification sub could look at its call
stack and see who was calling it and skip stringification if it was
Devel::StackTrace or Carp... But that is _really_ gross.
-ben
On Sat, Feb 21, 2004 at 04:01:39PM -0600, Dave Rolsky wrote:
On Sat, 21 Feb
Why do you hate me :-)
I have no idea how to handle this easily... is a bunch of sets the
right answer? Seems gross.
-ben
On Mon, Oct 13, 2003 at 01:00:09PM -0300, Flavio S. Glock wrote:
How about a question for the FAQ?
http://perlmonks.org/index.pl?node_id=298788
Calculate
Not that I have seen. This would be tricky to do right. I don't
think you can make arbitrary timezones easily.
Ideally the right thing to do would be to parse the TZ string and
find the Olsen entry that matches it, then use the Olsen ID.
In the cases where that does not exist, then you would
I agree with Joshua's intent. I think that the timezone selection
right now is the most difficult part of using DateTime if the user has
to specify it (and especially if you are not using a GUI).
I agree that changing DT::TZ is probably not the right thing to do.
Perhaps there should be a
No, I would like this too.
Perhaps the functionality can be rolled into DT::Alias somehow. They
seem related...
-ben
On Tue, Aug 12, 2003 at 08:02:02AM +1000, Rick Measham wrote:
What do people think? I can provide patches for this if I'm not the only
one who'd find it
I think it would be useful to make a set of TZ aliases per
country... like the US/Eastern, etc. stuff but for every country.
It would be even more useful to be able to break it down further as
needed (state by state and county by county as needed). But that is a
lot of work.
DateTime::Display::Calendar or
DateTime::Display::Calendar::Text (vs. HTML, etc.)
?
-ben
On Tue, Jul 29, 2003 at 10:46:59PM -1000, Joshua Hoblitt wrote:
Months ago I posted the beginings of a module that I called
DateTime::Format::Calendar. The discussion that
Ok, I am trying to fix the broken tests in DateTime::Event::NameDay
and am getting the error 'Span cannot start after the end in
DateTime::Span-from_datetimes'. However my span looks perfectly
valid...
So I boiled it down to a simple test case:
--
#!/usr/local/lib/perl -w
use strict;
use
On Mon, Jul 28, 2003 at 07:04:12PM +0200, Eric Cholet wrote:
Dave Rolsky wrote:
[...]
But don't latin-1 and utf8 overlap for the first 255 chars anyway?
No they don't. Common misconception it seems.
To clarify, UTF-8 and ASCII overlap, but any character with the high
bit set incicates that
Me too:
This is perl, v5.8.0 built for i386-linux-thread-multi
Linux ayup.limey.net 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003
i686 athlon i386 GNU/Linux
-ben
On Fri, Jul 25, 2003 at 02:17:23AM -0500, Dave Rolsky wrote:
On Thu, 24 Jul 2003, Joshua Hoblitt wrote:
I
Okay, I have renamed the module to DateTime::Format::Common and I am
getting ready to check in the rough version I have.
However I have a few questions I want to get resolved first:
1) Will DateTime 0.14 be the first release with locale support? If
so, when will you be bumping the version
On Tue, Jul 22, 2003 at 11:36:13AM -0500, Dave Rolsky wrote:
On Tue, 22 Jul 2003, Ben Bennett wrote:
1) Will DateTime 0.14 be the first release with locale support? If
Yes, and yes. I'll be releasing this stuff soon, I think.
Ok, in that case I will check it in with a dependency on .14
I committed it this afternoon (just the Locale change not the Common
parser).
-ben
On Tue, Jul 22, 2003 at 11:27:13AM -1000, Joshua Hoblitt wrote:
2) Can I add the sub _date_parts_order to the locales? I have the
patch to generate_from_icu that does this if you want
Do they call the standard and summer times different things?
The current DT::TZ stuff and POSIX::strftime and date on Linux and
Solaris all say EST in January and July... I have also seen it given
as EAST and EADT (actually I just checked www.worldtimezone.com and it
gives AEST, AES, EAST and
I like the idea (this is the partial date time thing right?) but I
am not too sure about the name... unless you start dealing with times
with real and imaginary parts :-) (Not that I have any suggestions for
a name yet).
Regarding the interface would it be better to have:
--
my $dtc1 =
S. Glock
Ben Bennett wrote:
I like the idea (this is the partial date time thing right?) but I
am not too sure about the name... unless you start dealing with times
with real and imaginary parts :-) (Not that I have any suggestions for
a name yet).
Regarding the interface
On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
[snip]
IMO. Also, I don't think DT::Infinite is in the same boat, because
that is a legitimate date (that DT::F::Simple must parse, BTW:
/^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error!
Is infinity really a
/PM and BC/AD are a bit of a problem, I may need to add
extra information somewhere).
-ben
On Wed, Jul 16, 2003 at 11:30:33AM -0400, John Siracusa wrote:
On 7/16/03 11:21 AM, Ben Bennett wrote:
On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
[snip]
IMO. Also
On Tue, Jul 15, 2003 at 01:56:53PM +1000, Iain Truskett wrote:
* Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]:
[...]
My quibble; the name. I'm not a huge fan of ::Simple and ::Lite.
Unfortunately, I can't think of a nice alternate for it.
Ok. I will think about that (suggestions
On Tue, Jul 15, 2003 at 12:14:00AM -0400, John Siracusa wrote:
On 7/14/03 11:10 PM, Ben Bennett wrote:
[...]
Sweet, someone took the bai--...er, picked up the baton ;)
Well I have been playing around with the idea for a while, but when
the locale stuff got in I decided it was time to stop
On Mon, Jul 14, 2003 at 11:39:37PM -0500, Dave Rolsky wrote:
On Mon, 14 Jul 2003, Ben Bennett wrote:
Which leads to my problem, there appears to be no simple way to get
the date order to differentiate m/d/y from d/m/y. I can look at the
time formats and try to work it out, but that seems
On Tue, Jul 15, 2003 at 11:40:16AM -0500, Dave Rolsky wrote:
On Tue, 15 Jul 2003, Ben Bennett wrote:
Actually, I was thinking that this would be done when generating the
locale modules. It shouldn't be _too_ hard, I think.
Sorry, that was where I was intending to fiddle with, I just
A bunch of the locales (e.g. ar_SY) have no date formats, but have
other stuff defined so they pass the has_data() check.
In this case I think they should inherit from their parent (ar).
However, there are some base languages (e.g. az) which have no date
format information defined but their sole
DateTime::Locale objects return references to internal data. So if a
caller changes things through the ref subsequent calls will see the
bogus data.
I am not sure if this is a problem or not, but we should at least
document that the caller _must_not_ change things through the ref.
It turns out that a handful of locales (e.g. af_ZA, en_ZA, fa, hr, hu,
ja ...) have dates with the form y/m/d.
So it looks like the value for the date component order (and the
optional parameter to DT::F::Simple) should be a string that can take
the 3 values:
'ymd'
'dmy'
On Tue, Jul 15, 2003 at 01:22:36PM -0500, Dave Rolsky wrote:
On Tue, 15 Jul 2003, Ben Bennett wrote:
[...]
As long as the fact that everything defaults to 'root' (which is basically
'en_US') is well-documented, I don't see a problem.
What you're proposing would mean that for many locales
fractional_seconds is deprecated... nanoseconds have to be specified
separately.
I dunno if Pg has been updated to use the new interface yet.
-ben
On Tue, Jul 15, 2003 at 12:30:39PM -0700, Alex Boster wrote:
DateTime::Format::Pg dies when I parse an ISO date. Can anyone
I vote that you assume the next valid instance of the time (e.g. if
they say 4 o'clock and it is 11 PM now, assume 4AM of the following
day).
I believe this is what Date::Manip does and it seems to be reasonable
most of the time.
As another possibility (which is what I did with my obsolete
On Sat, Jul 05, 2003 at 06:56:32PM -1000, Joshua Hoblitt wrote:
I want to preserve the revision history of my tree so the move to SF won't be until
next week.
Ok.
What really needs to be done is a lot more tests. I'm considering a framework for
building tests.
Ok, I can try to port over
Can you expand on this please?
-ben
On Sat, Jul 05, 2003 at 04:31:12AM -0400, Matt Sisk wrote:
Dave Rolsky [EMAIL PROTECTED]:
Can you and/or Joshua explain what this would be used for?
elbowing in
Unbounded clocks?
Matt
On Fri, Jul 04, 2003 at 09:11:22AM -1000, Joshua Hoblitt wrote:
I'm planning on moving my tree to SF CVS as soon as I return from OSCON. Then we
can merge as much as we can from your tree into mine.
I assume you have a personal CVS repository? Otherwise you can just
cvs add it over...
A
So is there any conclusion here? Should I commit my module or will
Joshua commit his?
-ben
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 know what that should be.
The basic usage should
wrote:
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
Ok, the new interface on mine is complete.
The only thing missing is POD and I will do that now.
The major problem with merging mine and Joshua's is that they take
totally different tacks for the implementation.
-ben
On Thu, Jul 03, 2003 at 08:56:39AM -1000, Joshua Hoblitt wrote:
Sorry to reply to myself, but the new version of this thing is
available at:
http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz
I think this is in roughly releaseable form. I still have some TODO
items in the code (actually marked with XXX) but they are small items
that clean
On Thu, Jul 03, 2003 at 12:01:33PM -1000, Joshua Hoblitt wrote:
We could use a DT::Duration::Set module for things
like once a week for 3 weeks
That would be ideal.
Especially if (given a start or end date) you can turn it into a
DateTime::SpanSet
How is that different from an ICal
On Tue, Jul 01, 2003 at 09:04:14AM -1000, Joshua Hoblitt wrote:
Looks good Ben. The timezone stuff must have been fun. :)
Fun in which sense of the word :-)
I ported a small piece of code (in production though) from Date::Manip to DT not
long ago. I've been meaning to post the diffs and
On Tue, Jul 01, 2003 at 07:36:48AM -0700, Hill, Ronald wrote:
Yes, and so will Date::Calc (that is what I use) But I wanted to use only
one
Date module. It makes no sense to use say Date::Calc with DateTime.
I know you provided a code snippet below, but in general when using
Date::Calc do you
On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky wrote:
2) Having a way to construct this directly would be nice being able
to make a duration that you can not directly construct seems odd.
Well, maybe. Right now the constructor is really simple, which is good.
More
I needed to convert between Date::Manip and DateTime so I wrote a
module to convert the date and duration formats (recurrences may
follow if there is demand, there are some nasty wrinkles though).
Get it from http://www.limey.net/~fiji/perl/
If people see no major problems with this module I
code.
-ben
On Wed, Jun 25, 2003 at 07:04:05AM -1000, Joshua Hoblitt wrote:
On Wed, 25 Jun 2003, Ben Bennett wrote:
All true... but my benchmarking as I wrote my ISO8601 showed that the
speed gained by pre-filtering by length to reduce the number of
regexps that need
have been using since I don't have a TZ object the TZ should be
able to tell me it's short name...
Thanks,
-ben
On Wed, Jun 25, 2003 at 01:50:39PM -0500, Dave Rolsky wrote:
On Wed, 25 Jun 2003, Ben Bennett wrote:
my $short = DateTime::TimeZone-short_name_for_datetime($dt
On Mon, Jun 23, 2003 at 12:34:13AM -0500, Dave Rolsky wrote:
Also, I'm not entirely against the idea of folding all the alias stuff
into the main DT::TZ module. It doesn't seem like an entirely wack idea,
though I'd be glad to hear why I'm wrong ;)
I think this is the right thing to do.
A
Yeah, I know. That is what rang the initial warning bell.
Frankly the functionality provided by Alias seems to be vital to the
TZ package anyway. (Kudos for writing it).
-ben
On Mon, Jun 23, 2003 at 10:11:02AM -1000, Joshua Hoblitt wrote:
A little voice has been saying that
On Sun, Jun 22, 2003 at 04:47:42AM +0200, Eugene van der Pijll wrote:
If YY really is the century, you should probably return Jan 1st, 1901
when given 20...
The example given in the spec says that given 12 April 1985 YY gives
19. So they are being a little loose with the word century...
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).
-ben
On Sun, Jun 22, 2003 at 01:37:24AM -0500, Dave Rolsky wrote:
On Sun, 22 Jun 2003, Eugene van der Pijll wrote:
Check out Dave's work on the POD to HTML stuff for the FAQ for a
start...
-ben
On Sun, Jun 22, 2003 at 06:41:16PM -0500, Dave Rolsky wrote:
On Sun, 22 Jun 2003, Dave Rolsky wrote:
On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
Should I add the namespaces doc to
Fantastic! Thank you for the summary, I will add it to the FAQ (with
appropriate attribution of course).
-ben
On Sun, Jun 22, 2003 at 10:36:02PM +, [EMAIL PROTECTED] wrote:
Thanks Eugene.
I'll try to rephrase this, because it
would be good to have it in the
I will try to have something usable by tomorrow... I made some decent
progress last night.
-ben
On Fri, Jun 20, 2003 at 01:08:13PM +1000, Iain Truskett wrote:
* Ben Bennett ([EMAIL PROTECTED]) [20 Jun 2003 12:59]:
On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote
I am still in the thinking about this phase...
I am not sure what your mean by 'logical progression' etc. Do you
mean the current state or the ideal future state that the frightening
email thread alludes to?
I was under the impression that the Pataphysical calendar was
basically a fictional
Is this for taking an ISO week number and day of week and getting a
month, day and year back?
Dave, would it be possible to have a DT constructor for this? There
is an accessor (week()) that does the reverse... For the ISO8601
module it would be nice to have this, although it is easy enough to
I have made my rough ISO8601 parser available at:
http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz
Since this is a rough first release there are huge things wrong with
it. An incomplete list is:
- No documentation
- Module name not settled yet
- Only parses
Well that was always my intention. I plan to allow the caller to
specify what exact rules to use since the spec basically allows very
little unless the parties agree.
However, I think that the default format (if nothing was specified)
should allow for parsing of common ISO8601 formats.
This
On Wed, Jun 18, 2003 at 06:42:06PM -1000, Joshua Hoblitt wrote:
[...]
When I started writing DateTime::Format::ISO8601 I was using the ordering method.
Although I think it maybe necessary to to use both 1 and 2. Someday I may finish
this module - what name are you planning on using?
I
On Wed, Jun 18, 2003 at 10:14:32AM -1000, Joshua Hoblitt wrote:
Hi Dave,
Two questions:
1) When is fractional second support going to be dropped?
Already dropped in CVS. So whenever the next release happens...
I agree that we need to fix the ns support when switching calendars.
Ok. So ISO8601:2000 defines all sorts of things, some of which are
impossible to distinguish from one another without outside
information:
+yMMDD Extended complete year
+yDDD Extended ordinal day in year
-YYMM Year and month in implied century
-DDDOrdinal day in implied
I have actually been thinking about that a bit...
The way it is shaping up is that it will be a generic DT::SpanSet
wandering thing... So given a SpanSet (or Set, or Span) it will be
able to do operations within its context (i.e. date arithmetic,
etc.).
DT::E::BusinessDay would simply be a
On Tue, Jun 17, 2003 at 09:52:46AM -1000, Joshua Hoblitt wrote:
Btw - US/Eastern is defined as an alias unless you removed it earler in the program.
Yeah, that is why I have to jump through more hoops in my example.
How would an add method that returns silently if an alias is already
Ok. It is your module so this is your call.
I disagree, but that is ok. This should end the thread.
-ben
On Tue, Jun 17, 2003 at 01:26:43PM -1000, Joshua Hoblitt wrote:
my $dta = DateTime::TimeZone::Alias;
$dta-remove(EST);# Start with a clean slate
Is that a generic business calculation or just an application of sets?
I think the latter. You can just make a set representing the
intersection of mondays (or weekdays) and Dec. 31sts. Then iterate
over it (using the restricted time range) to find the solution.
--
use strict;
use DateTime;
Isn't that simply:
my $safe_span = ...;# Whatever you need
my dt = DateTime-new(...);
croak Bad date range if $safe_span-contains($dt);
In fact you may want the span to be a spanset to accomodate more fine
grained controls. Is this useful enough to merit a class? I dunno.
As a minor
Dave already said that he was open to adding a flag to control the
overflow behavior if anyone could provide a valid reason for needing
it.
It sounds like you have a good reason, so post it and see if he will
add the flag.
-ben
On Mon, Jun 16, 2003 at 08:43:50AM -1000, Joshua Hoblitt
Ok, lets say that you want only working hours as legal times, so
9-12,1-5, M-F from July 1st to July 17th, 2003.
Most of the code below is building the ranges... I think youy would
have to do that anyway. The real bit that the module would do is the
intersection stuff, and that is a couple of
Ah! nice. I don't fully understand DT:E:Recurrence yet...
Slight correction to both scripts:
The hours should be 13 and 17 instead of 1 and 5 (damn PM...).
Then yours should be (otherwise it picks up Saturdays too):
days = [1..5]
Which is more clear than mine anyway...
-ben
I think DateTime::TimeZone::Alias 0.03 is really looking good. The
docs are excellent (small patch to fix typos included below).
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?
i.e. If I have aliased EST to
On Mon, Jun 16, 2003 at 12:01:21PM +1000, Iain Truskett wrote:
That version isn't on CPAN yet. To be honest, I'd really
like the validation to be optional. While some people have
more use for validation rather than normalization, others
(like me) are the opposite =)
I half agree. Initially
, \n; # Prints: ns: 4200\n
=for example end
=for example_testing
is($_STDOUT_, ns: 230\nns: 4200\n, Nanoseconds);
-ben
On Wed, Jun 11, 2003 at 10:05:02PM -0700, Bruce Van Allen wrote:
On Wednesday, June 11, 2003, at 07:08 PM, Ben Bennett wrote:
I added
Please ignore the last one... I biffed it too. Below is the corrected
POD.
-ben
=head3 How small an increment of time can I represent?
ADateTime can represent nanoseconds. You can create obects with
that resolution using the Cnanosecond parameter to Cnew or Cset
and there is
I knew I had seen the assertion that qr started in 5.6.0 somewhere
recently and finally found it:
Perl 5.6.0 introduced the ability to package up regular expressions
into variables using the qr// operator.
[From Simon Cozen's article on regexps
Cool. I want to mention it in the FAQ and I want to use it in the
Complex parser...
-ben
On Wed, Jun 11, 2003 at 03:33:09PM -1000, Joshua Hoblitt wrote:
Any progress on this?
I seem to recall that Rick volunteered to do it but I don't see that in the thread.
I just
I added a section on nanoseconds:
http://www.limey.net/~fiji/perl/faq.html#2.9%3A%20How%20small%20an%20increment%20of%20time%20can%20I%20represent%3F
The raw POD is below.
I deliberately did not mention fractional_second since Dave suggests
that it is going away... If this is not true, please
Any progress on this?
-ben
On Wed, Apr 30, 2003 at 12:30:01PM +1000, Rick Measham wrote:
On Tue, 29 Apr 2003, Joshua Hoblitt wrote:
I was thinking of something similar to the 'constant' syntax that
quietly creates namespaces.
use DateTime::TimeZone::Alias HST =
Ah.
I am working on that. I decided to use Parse::RecDescent as a base.
I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime
complete?) and I have it parsing simple dates and times...
Next on my list is making it understand all of the weird and wonderful
things that Date::Manip can
That's too bad.
Anway, I am going to keep playing with this for a bit until I get all
of the functionality I want, then I can convert it to a re-based
thing.
-ben
On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote:
On Tue, 10 Jun 2003, Ben Bennett wrote:
However, I
at 01:32:14PM -0700, Brad Hughes wrote:
Ben Bennett wrote:
Okay so what should a business date module be able to do?
What is a business day?
A quick glance at our internal date modules reveals over 40 different
business day calendars. You've got, for example, the NYSE, NASDAQ,
AMEX, CBOE
I think I am leaning towards the following:
Have a module that can perform special date arithmetic. So you load
the definition of good times and bad into an object (through the
constructor and accessors) and can then perform calculations on dates
as calls through the object.
Something like:
---
Okay so what should a business date module be able to do?
As a first cut:
- Business day arithmetic:
- Addition
- Subtraction
- Differences (how many b. days between X and Y)
- Know about holidays
- Have settable weekend day(s)
- Know about business hours
- Way to say if a given DT
I will add it to the FAQ...
-ben
On Mon, Jun 02, 2003 at 07:46:54AM -0700, Hill, Ronald wrote:
Hi Jean Ben,
From Ben Bennet (Fri, 30 May 2003 15:24:13 -0400)
OK, it looks like it is bombing because of all of the modules to
install... each timezone module looks like:
[snipped]
I still think it is a MakeMaker problem, has anyone reported it to
them?
I plan on adding it to the FAQ until we get it resolved properly.
-ben
On Mon, Jun 02, 2003 at 08:24:24AM -0700, Hill, Ronald wrote:
Hi John,
Rather than document it, is there any way to fix the
Typos in POD that I spotted during FAQ development:
1) DateTime::Format::Strptime: This method is synonymous with
DateTime's strptime method.
2) DateTime: DateTime does not if second values greater than 59 are
valid based on current leap seconds, and invalid values simply
cause an
of the overloadable
operators, but there are some nasty twists that way... Perhaps I will
look at that again.
-ben
On Sun, Jun 01, 2003 at 12:02:06PM -0500, Dave Rolsky wrote:
On Fri, 30 May 2003, Ben Bennett wrote:
This class allows you to wrap an arbitrary object
Claus Tondering's calendar FAQ[1] has some information about this in
sections 4.2 and 4.5.
4.5 says that Saudi Arabia has adopted a calendar based on a
calculated astronomical moon (at Mecca).
This is actually the reason that I wanted to get a Moonrise package
working...
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
30, 2003 at 01:46:57PM -0500, Dave Rolsky wrote:
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
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
Sorry to reply to myself, but the problem is even more interesting,
DateTime::Set doesn't have a constructor named new. Perhaps the right
thing to do is call DateTime::Span-new(), but I leave that to less
tired people to work out.
-ben
On Thu, May 29, 2003 at 10:41:12PM -0400, Ben
On Thu, May 29, 2003 at 11:59:21PM -0500, Dave Rolsky wrote:
First I'll pick some nits.
- Assume it will be hosted on datetime.perl.org, so you can skip the first
4 questions.
I dunno, 1.1 to govern the scope of the FAQ seemes relevant as does
the reference to Claus' FAQ in 1.3. I haven't
90 matches
Mail list logo
