On Thu, 17 Jul 2003, Nick Porter wrote:
> I really want to play with this module but I just can't get the thing to
> make. I'm no guru or coder I just muck about with perl so working out how to
> install DateTime-0.13 into ActivePerl using CPAN was an effort in itself.
> I've got all the dependenc
On Wed, 16 Jul 2003, Joshua Hoblitt wrote:
> ./tools/generate_from_icu --dir icu-xml
> Reading ICU files from: 'icu-xml'...
>
> af
> af_ZA
>
> And then it hangs indefinitely. Any ideas?
Upgrade XML::Simple and/or maybe install the latest XML::SAX. I think
it's the XML parser hanging.
-dav
On Wed, 16 Jul 2003, Eugene van der Pijll wrote:
> But no part of DateTime, the base module, should return these non-dates.
> They should only be a result of some action where it makes sense that
> something else than a date is returned.
>
> Specifically, the default parser should not return these
On Wed, 16 Jul 2003, Joshua Hoblitt wrote:
> > Do all of these have different datetime formats? If database X has the
> > same formats as e.g. Pg, it doesn't need a separate format. Of course
> > DT::F::DBI should know about these cases.
>
> If X has identical date/time handling as Pg I'd like to
On Wed, 16 Jul 2003, Joshua Hoblitt wrote:
> Pheonix
First of all, it's "Phoenix", and second of all, you're thinking of
Firebird. Don't get that name wrong or they'll come down on you like a
ton of bricks ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Tue, 15 Jul 2003, Joshua Hoblitt wrote:
> We were talking about returning DT::Undef objects from parsers. So, for
> example, if the _format_ being parsed _defines_ an unknown or undefined
> date/time an object can be returned that reflects this. Simply
> returning undef when an object is expe
On Tue, 15 Jul 2003, Joshua Hoblitt wrote:
> > > 2. My option:
> > > $day_of_month = ;
> > > $dt->set( day => $day_of_month )->truncate( to => 'day' );
> > > print "Your day must be a number in the current month" if
> > > $dt->is_undef;
> >
> > See, most people won't _bother_ with the 3rd li
On Wed, 16 Jul 2003, John Siracusa wrote:
> Here's my take on handling parse errors, and error handling in general.
>
> 1. I don't like to (unconditionally) die from within libraries except for
> conditions that are totally avoidable. For example, I die if you forget to
> send a required argument
On Wed, 16 Jul 2003, Rick Measham wrote:
> At 3:42 PM +1000 16/7/03, Iain Truskett wrote:
> >What do people think parsers should return if they can't
> >parse? And what if they do parse, but DateTime doesn't want
> >to create an object of the appropriate specification?
>
> DateTime::Undef :)
>
> I
On Wed, 16 Jul 2003, Iain Truskett wrote:
> What do people think parsers should return if they can't
> parse? And what if they do parse, but DateTime doesn't want
> to create an object of the appropriate specification?
>
> Should we wrap our methods in evals and return undef?
>
> Should we just th
On Tue, 15 Jul 2003, Hill, Ronald wrote:
> Test report for the CVS version of datetime. Is there
> a better place to post test results other than on
> the newsgroup?
Nope, this is good.
> t\13strftime..NOK 41# Failed test (t\13strftime.t at line 44)
> # got: 'Sep 7, 1999 1:0
On Tue, 15 Jul 2003, Ben Bennett wrote:
> 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
On Tue, 15 Jul 2003, Ben Bennett wrote:
> However, there are some base languages (e.g. az) which have no date
> format information defined but their sole child (e.g. az_AZ) has them.
> The problem in this case is that the dates defined by az_AZ are of the
> form dd.MM., but root is M/d/yy so s
On Tue, 15 Jul 2003, Flavio S. Glock wrote:
> I think this is related to an older version of DateTime::TimeZone.
> I installed the latest from CPAN and it just worked.
>
> Did somebody else get errors with DateTime::Set?
Works for me.
-dave
/*===
House Absolute Consulting
w
On Tue, 15 Jul 2003, Ben Bennett wrote:
> > We'd have to look at the _actual_ format strings to do this, but it's
> > certainly possible.
>
> Ok, I will play around with this and see if all of the locales have
> understandable short forms.
Actually, I was thinking that this would be done when gen
On Tue, 15 Jul 2003, Ben Bennett wrote:
> > and maybe even:
> >
> > 200210131:02
>
> No! Egads :-) Actually I wasn't accepting the form 200210130102
> either (I will accept 20021013T0102). Should I?
Is the former form unambiguous? If so, you mighta s well accept it.
> > Also, don't forge
On Tue, 15 Jul 2003, Ben Bennett wrote:
> > > Ommissions from Date::Parse:
> > > - July 14th will not be parsed (I don't have localized info on the
> > >numeric suffixes)
> >
> > How about you just assume /\d{1,2}\w+/?
>
> Perhaps, I will play with it when the rest is finished. Input from
>
On Tue, 15 Jul 2003, John Peacock wrote:
> > if (length($yr) < 4)
> > warn ("Your year value is indeterminant. Performing SWAG[1]!");
>
> Then do a search on Google for "y2k window" and see how people suggested
> handling it. Yes, it _is_ completely bogus and arbitrary, why do you ask? But
If people on non-Unix platforms could try this out I'd be quite grateful.
I'm especially interested in hearing from Win32 and Mac users. Also, if
anyone has a platform where time_t is not a 32-bit int, that'd be another
interesting place to test.
1.07_90
- Fixed behavior for edge cases like tim
On Tue, 15 Jul 2003, Rick Measham wrote:
> Will this be useful to anyone other than me?
Yes, I think it's somewhat useful for end users and definitely useful
other module authors.
> Is there a better name?
I sure hope so, because I _really_ don't want to see something called
DT::Event::DT on CP
On Mon, 14 Jul 2003, Joshua Hoblitt wrote:
> > 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.
>
> I usually think of ::Simple as referring to a reduced interface. Maybe
> ::Basic is a better namespace.
I like ::Common
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 a bit dodgy if you
> ever change the parser, plus I assume that
On Mon, 14 Jul 2003, John Siracusa wrote:
> On 7/14/03 7:00 PM, Iain Truskett wrote:
> > My only qualm is the default American bias of the second regex.
>
> Right, which is why I mentioned some sort of mode/setting. But it'd still
> default to US, so there ;) Heh, maybe it'd look at your current
On Mon, 14 Jul 2003, Flavio S. Glock wrote:
> > > On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
> > > > It would be easy to change the Perl code generator into a C code
> > > > generator. Then you could use DT::LeapSecond at compile time, if they
> > > > are using XS, or at runtime, if they are usi
On Mon, 14 Jul 2003, John Siracusa wrote:
> > That is another reason why I suggest not having the parser() and parse()
> > methods in DT at all. For people who never need to parse random date strings,
> > they only "use DateTime;" and they are done; everyone else does "use
> > DateTime::Format;"
On Mon, 14 Jul 2003, John Siracusa wrote:
> On 7/14/03 1:05 PM, Dave Rolsky wrote:
> > Anything called DT::F::Simple should parse everything Date::Parse can
> > parse, at least, and not _too_ much more, because it should also be
> > reasonably fast ;)
>
> Great, but
On Mon, 14 Jul 2003, John Siracusa wrote:
> Also, I'm slightly confused about the "responsibilities" of a
> DateTime::Format:: module. Does such a module have to have format_*
> methods, or can it get by with just parse_datetime()? I'm not sure what a
> format_* method for ::Simple should produc
On Mon, 14 Jul 2003, Hill, Ronald wrote:
> > On Sunday, July 13, 2003, at 08:11 PM, Iain Truskett wrote:
> > > Remember: part of the point of having the various format
> > > modules is that you can pick'n'mix. You could conceivably
> > > wrap a number of them in Builder to make your own parser
> >
On Mon, 14 Jul 2003, Rick Measham wrote:
> Maybe an example will explain why I want to have an undef DateTime:
>
> print $natural->parse_datetime("Feb 29th, this year")
> ->set( day => 31 )
> ->add( days => 12)
> ->datetime;
>
> Of course, this won't always work because:
> 1. the
On Sun, 13 Jul 2003, Joshua Hoblitt wrote:
> > Oh, and while we're at it, can there be any way to set an undefined
> > datetime object constructor:
> >
> > $undef = DateTime->undef();
>
> If Dave OKs this it should be a separate class. Probably DT::Undef.
If Dave OKs? Does that ever happen. Un
On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
> It would be easy to change the Perl code generator into a C code
> generator. Then you could use DT::LeapSecond at compile time, if they
> are using XS, or at runtime, if they are using pure Perl.
But the point is to avoid having to cross the Perl->C
On Sun, 13 Jul 2003, Rick Measham wrote:
> > On Sun, 2003-07-13 at 17:09, Dave Rolsky wrote:
> > Now I'm confused. Are you proposing that there be a language parameter
> > _and_ a locale parameter?
>
> Hmmm .. well I was going to make it a case of 'use one or th
On Sat, 13 Jul 2003, Rick Measham wrote:
> On Sat, 12 Jul 2003, Ben Bennett wrote:
> > Does it understand 1/3/2003? If so, how does it resolve the day and
> > month ambiguity?
>
>
> On Sun, 2003-07-13 at 12:46, Dave Rolsky wrote:
> > Ideally, it'd be an attri
Why is the directory called DateTime-Event-NameDay-0.02? Ben, can you ask
SF to change this, please?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sun, 6 Jul 2003, Joshua Hoblitt wrote:
> Available immediately from:
>
> http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Cache-0.01.tar.gz
>
> I'm not sure if this should be DateTime::Util::Cache instead. I prefer
> the Util::* namespace but I wanted to keep the name as short as
> possible.
I recently checked in the DT::Locale code to SF CVS. Just now, I also
checked in the changes necessary to make DateTime.pm use it. It seems to
work quite well, from my limited testing.
There's a couple more things I want to do before a release:
- Decide how to handle default format length. Ric
On Sat, 6 Jul 2003, Rick Measham wrote:
> On Sun, 2003-07-06 at 09:27, Matt Sisk wrote:
>
> > I was terming a 'clock' as anything with periodicity. An 'unbounded' clock would
> > be a clock without an associated epoch or starting date.
> >
> > A clock without context still has characteristics and
On Fri, 4 Jul 2003, Joshua Hoblitt wrote:
> > That's all correct, and the implementation is
> > cut-and-paste DT::Set/DT::E::Recurrence code.
>
> Well I have it strait in my head now. :)
>
> > Dave wants to know _why_ we want this!
>
> ISO8601 recurring time intervals.
And what _are_ these, and w
On Fri, 4 Jul 2003, Flavio S. Glock wrote:
> Joshua Hoblitt wrote:
> > I'm planning on working with Iain and Flavio for any changes needed
> > to DT::F::Builder or DT::Duration::Set (when it's written).
>
> Ok, how about this for DT::Duration:Set:
Can you and/or Joshua explain what this would be
On Fri, 4 Jul 2003, Joshua Hoblitt wrote:
> > The DT::Set::ICal class is inlined into DT::E::Recurrence.
> > Maybe it should be published separately?
>
> I think so - not everyone that uses DT::E::Recurrence will want it.
So what? It's 69 extra lines, and it doesn't really have much use outside
On Thu, 3 Jul 2003, Jesse Shy wrote:
> Yes, please, tell me what to change. I dont know what it should have been.
> I looked at the date time module and the DateTime-TimeZone modules for
> examples and read the standards from the web site. So I used named
> parameters, did I miss something that s
On Thu, 3 Jul 2003, Flavio S. Glock wrote:
> On Thu, 3 Jul 2003, Flavio Soibelmann Glock wrote:
> > $base_set->{set}{as_ical} = [ uc('recur:'.$recur_str) ];
>
> Dave Rolsky wrote:
> > use a subclass of DateTime::Set.
>
> Ok, I think it might work. How
On Thu, 3 Jul 2003, Joshua Hoblitt wrote:
> > Well mine currently does that and parses durations...
>
> I already said I'd be happy to use your module for parsing durations if
> you beat me to it.
>
> I set the bar low enough to get something stable for release.
Joshua, why don't you check yours
On Thu, 3 Jul 2003, Ben Bennett wrote:
> There is a lot to work out, but once the interface is clear it should
> be very quick to implement.
>
> Do you have any suggestions for what the interface should be or should
> I just take a whack at it and see what people think?
Probably for unambiguous c
On Thu, 3 Jul 2003, Jesse Shy wrote:
> I think I got everything up that is needed.
I want to change the API a bit, to be more like the other DT modules.
Right now it's not even close to the other modules.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
=
On Thu, 3 Jul 2003, Ben Bennett wrote:
>
> I am not sure what interface to use for the advanced features of the
> ISO8601 parser I wrote. Right now I use a quick hack to make it work
> so I can test the parser. It should be easy for me to change the
> interface to something sane, I just don't kn
On Thu, 3 Jul 2003, Ben Bennett wrote:
> Well mine currently does that and parses durations...
>
> Joshuas can probably be changed to do so, but I am not motivated to
> do the work.
So, no offense to Joshua, I think yours should be the one with the
DT::F::ISO8601 namespace. I don't see the need
On Thu, 3 Jul 2003, Ben Bennett wrote:
> I am okay with this decision. However Joshua's parser does not allow
> selection of which pieces of the spec are applicable so you can have
> ambiguous cases.
>
> Anyway, I will rename my parser to
> DateTime::Format::ISO8601::Complete and release it.
Ugh
On Tue, 1 Jul 2003, Joshua Hoblitt wrote:
> Agreed. I think it should boil down to recurrences and durations.. If
> most people need that functionality then lets call your module
> DT::F::ISO8601 and I'll use ISO8601::Simple. If they don't then I'll
> take ISO8601 and you can use ISO8601::Compl
On Tue, 1 Jul 2003, Hill, Ronald wrote:
> >
> > You can do "./Build dist". The latest Module::Build beta
> > (0.18_02) also
>
> I tried this. Here is the result.
> Creating DateTime-TimeZone-0.21.tar.gz
> Can't locate object method "create_archive" via package "Archive::Tar" at
> F:\pe
> ild/Base
On Mon, 30 Jun 2003, Joshua Hoblitt wrote:
> > Why not:
> >
> > $dur1 = new DT::Dur( days => 2 );
> > $dur2 = new DT::Dur( months => 1 );
> > $dur3 = $dur1 - $dur2;
> > $dur3->add( days => 3 );
> >
> > If you add $dur3 to a date, it would add 2 days and
> > subtract a month, then add 3 days again.
On Mon, 30 Jun 2003, Matt Sisk wrote:
> Found the parse_recurrence docs in the CVS, thanks.
>
> However, there's a good reason the format_recurrence method is not
> documented...it doesn't exist.
>
> Are there plans to implement this?
This is hard, since recurrences are implemented as closures/co
On Mon, 30 Jun 2003, Matt Sisk wrote:
> So, yes, the implication is that:
>
> $dur = DT::Dur->new(days => 2, months => -1);
>
> would indeed behave differently than:
>
> $dur = DT::Dur->new(months => -1, days => 2);
>
> So long as the behavior (intrinsic to durations) is well documented I thin
On Mon, 30 Jun 2003, Ben Bennett wrote:
> I am totally mystified. I read "If any of the numbers are negative,
> the entire duration is negative." as indicating that the individual
> signs don't matter.
>
> I think the error is on DT::Duration line 52:
> $self->{minutes} = abs( ( $p{hours} * 60
On Mon, 30 Jun 2003, Flavio S. Glock wrote:
> > Well, maybe. Right now the constructor is really simple, which is good.
> > More functionality is nice, but so is simplicity.
>
> use DateTime;
> my $dt = DateTime->now;
> my $dur = sub { $_[0]->add( months => 3 )->subtract( hours => 3 ) };
> print
On Mon, 30 Jun 2003, Ben Bennett wrote:
> The nits:
> 1) The following doesn't work because add_duration() doesn't return
> the object, but rather falls through and returns the number of
> nanoseconds in the final object:
> --
> my $dur = DateTime::Duration->new(months => 3)->add(hour
On Sun, 29 Jun 2003, Joshua Hoblitt wrote:
> I just noticed your on MJD's lightning talk list for OSCON. What are
> you going to cram into 5 minutes? :)
Um, I dunno. I figured I'd write it that day or something. I'm mostly
planning on just telling people what the project is and why it's a good
I thought that this was going to be the parent namespace, not the actual
module name, right?
I don't think we should co-opt the whole namespace for a module which just
provides a few simple pieces of functionality.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
On Sat, 28 Jun 2003, Joshua Hoblitt wrote:
> I received this bug report on one of my modules. Is this a known
> problem with Module::Build or nmake?
Module::Build doesn't use make, so instead of "nmake test" you need to do
"./Build test" or ".\Build test".
-dave
/*===
Hous
On Sat, 28 Jun 2003 [EMAIL PROTECTED] wrote:
> # Failed test (t/01datetime.t at line 87)
> # got: 'TZID=-0100:19000101T15'
> # expected: '19000101T16Z'
> # Looks like you failed 1 tests of 37.
>
> my $dt = DateTime->new(
> year => 1900, hour => 15, time_zone => '-01
On Sat, 28 Jun 2003, Rick Measham wrote:
> This is just for comment. As per my previous email, this module allows
> one to compare durations when given a reference point. I'm not real
> happy with the method names, and I've just called it
> DateTime::Duration::Compare for the time being.
> DateTim
On Fri, 27 Jun 2003, Flavio S. Glock wrote:
> You could use the name "DateTime::File::Ics"
> or "DateTime::File::ICal"
What would the DT::File namespace be for? I don't want to arbitrarily add
new namespaces.
This sounds to me like two modules: DT::Format::ICS and DT::Event::ICS.
-dave
/*===
On Thu, 26 Jun 2003, Joshua Hoblitt wrote:
> > Hmm, this is a problem. I'm really not sure subclassing makes that much
> > sense here. At the very least, you probably need to provide your own
> > new() method.
>
> The DT constructor is pretty large - not much fun.
It can be broken up into multi
[ moved ot the list ]
On Thu, 26 Jun 2003, Joshua Hoblitt wrote:
> In the case of DT::C::Egyptian inheritance makes a lot of since. The
> Gregorian calendar only needs minor tweaks to function as the Egyptian
> one. Why should everyone have to reinvent the entire wheel instead of
> sub-classing
On Thu, 26 Jun 2003, Flavio S. Glock wrote:
> yet another object = slower program
At least for DateTime.pm, I think this is enough for me to not use it.
Given the fact that the internals work fine now, I don't see a good reason
to change them.
It seems to me that converting between calendars i
Ugh, my release management skills stink. Hopefully there won't be another
release with this many changes at once for a _long_ time (or better yet,
never!).
I gave up on Win32 and made a hack to skip the failing test. I figure
that the infinite datetime stuff is marginal enough that it's better t
0.21 2003-06-25
- Switched to Module::Build, which should fix the installation
problems caused by very long Makefile lines on some platforms.
- Fixed a bug in finding the correct data for a given datetime. This
could occur when calling set_time_zone on an object that was very
close to a DST
On Wed, 25 Jun 2003, Ben Bennett wrote:
> my $short = DateTime::TimeZone->short_name_for_datetime($dt);
This is an object method, not a class method.
> On a related note, while trying to chase this problem I noticed that
> DT::TZ->span_for_datetime() compares $type to "UTC" to determine $end,
>
On Mon, 23 Jun 2003, Joshua Hoblitt wrote:
> I think you probably never got the original email with this patch (it
> was sent while you reported having difficulties). The general idea was
> to do something like the following and then update the calendar docs so
> nanosecond precision is always pr
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> > > DT::TZ::LINKS is still the only internal structure that is modified.
> >
> > Yes, but you access @DT::TZ::ALL as well.
>
> I was necessary to verify that what an alias was pointing to was valid.
> Once the dependency was already there I implemented
On Sun, 22 Jun 2003, Ben Bennett wrote:
> Check out Dave's work on the POD to HTML stuff for the FAQ for a
> start...
Actually, the FAQ is much more complicated. For the other docs I've just
been doing
perl -MPod::Simple::HTML -e \
"Pod::Simple::HTML->filter(shift)" \
and then hand-e
On Sun, 22 Jun 2003, Richard Evans wrote:
> * Added new locale generator (ICUGenerator.pl) which is not derived from my
> other work - this is largely untested. Locale data is not supplied and must
> be generated from ICU .xml sources.
Thanks, this looks great.
> * All manually edited code remov
On Sun, 22 Jun 2003, Dave Rolsky wrote:
> On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
>
> > Should I add the namespaces doc to web/htdocs/developer/?
>
> Sure, please do.
BTW, you should use Pod::Simple::HTML for the conversion, not pod2html
that comes with Perl. The latter pr
On Sun, 22 Jun 2003, Joshua Hoblitt wrote:
> Should I add the namespaces doc to web/htdocs/developer/?
Sure, please do.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sun, 22 Jun 2003, Ben Bennett wrote:
> I used to live in Saudi Arabia and the weekend was on Thursday and
> Friday (I don't know what calendar businesses used but I will ask my
> father).
If it was on Thursday and Friday it was still following the Gregorian
calendar though. That was my basic
On Sun, 22 Jun 2003, Jesse Shy wrote:
> OK , I am coding up the port from Date::Calc::Fiscal right now. I should
> have something for y'all to look at by the end of the day ( I hope ). I
> will still have to write docs and test. It will have only 2 methods right
> now, day_fiscal_year - if Mar 1 i
On Fri, 20 Jun 2003, Eugene van der Pijll wrote:
> Peter J. Acklam schreef:
> > I could have sworn the difference was 0 seconds between 1970-01-01
> > and until the leap second in June 1972. I should have checked
> >
> > ftp://maia.usno.navy.mil/ser7/tai-utc.dat
>
> By the way, according to the
On Sun, 22 Jun 2003, Eugene van der Pijll wrote:
> Businesses in Israel, Iran and in the Arab world probably use a business
> calendar based on the Hebrew, Jalali and Hijira calendars. It would be
> nice if one module could be used for the Gregorian calendar and for
> these three calendars.
Actua
On Sat, 21 Jun 2003, Bruce Van Allen wrote:
> One thought: A "fiscal year" is type of calendar, and as the (long-ago)
> DT consensus was that all "calendars" are adopted fictions, perhaps it
> should be DT::Calendar::FiscalYear. The API would have to be somewhat
> different from the existing DT::C
On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
> DT::TZ::LINKS is still the only internal structure that is modified.
Yes, but you access @DT::TZ::ALL as well.
> > almost certainly does not belong in a module called Alias! Why does
> > it
>
> Probably not - but what ever module handles the aliasing
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> > It is not clear to me what a value like 2003-06 would mean. Is it "a
> > timepoint somewhere in June 2003" (an imprecise datetime), or is it "all
> > timepoints in June 2003" (a datetime span)?
>
> This is why I feel the need for time only objects or
On Sat, 21 Jun 2003, Richard Evans wrote:
> On Saturday 21 Jun 2003 4:16 am, Dave Rolsky wrote:
> > On Sat, 21 Jun 2003, Richard Evans wrote:
> > > The one exception to this would be additions, and in that case I can
> > > generate any new locales for the time being
On Sat, 21 Jun 2003, Jesse Shy wrote:
> I would like to tackle number one below by porting what I have from
> Date::Calc; I am taking this as implicit permission to use the
> DT::Business::FiscalYear namespace for this OK?
That seems like the best namespace to me. Anyone else have thoughts on
th
On Sat, 21 Jun 2003, Bruce Van Allen wrote:
> There's been quite a bit of talk about how to handle date and time for
> business & fiscal applications. I urge _not_ trying to create a
> comprehensive module.
>
> Instead, an extensible framework, within a DT::Business or DT::Fiscal
> namespace, coul
On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
> Here is a small patch that allows you to create a DT::Language object by
> just calling new on it (and thus not being trapped into the DT::Language
> namespace).
>
> This should tie me over until locale is officially released. :)
You'll be happy to know
On Sat, 21 Jun 2003, Jesse Shy wrote:
> Maybe I should include my ugly little hack for Data::Calc and how I am
> employing it an a live application?
Please do. I think that basing what we start with on existing, in-use
code, is definitely a reasonable idea.
While I know that DateTime::Business
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> > There is a DateTime->from_day_of_year constructor.
>
> In the CVS version - what is the ETA for the next release?
The only thing I've been waiting on for a while is a resolution of the
Win32 problems. If we can't find a proper fix very soon (like by
Any progress on this? If not, I'll probably throw in a hack in the
DateTime.xs to just not compile _normalize_seconds on Win32, because I
really want to make a new release of DateTime.pm, and I don't want to wait
much longer for the Win32 fixes.
-dave
/*===
House Absolute Co
On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
> We are thinking about having two different modules. Or I'm willing to
> throw mine away if it's just going to be superfluous.
>
> DateTime::Format::ISO8601::Complex
> DateTime::Format::ISO8601::Simple
>
> The question is should there be a DT::Format::I
On Sat, 21 Jun 2003, Ben Bennett wrote:
> - Module name not settled yet
What other name would you use? DT::F::ISO8601 seems pretty logical to me.
Why not check it in with this name?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Fri, 20 Jun 2003, Joshua Hoblitt wrote:
> > I can't think of any other usage which necessitates such a constructor.
>
> strptime needs it.
Actually, if we're going to emulate the C library's strptime() then it's a
_different_ week number. In fact, there's two different ones strptime()
handles
On Sat, 21 Jun 2003, Richard Evans wrote:
> The one exception to this would be additions, and in that case I can generate
> any new locales for the time being - I'm not saying that I'll never release
> the generator code, simply that it's not feasible in the short term.
Why isn't it feasible? Ju
On Sat, 21 Jun 2003, Ben Bennett wrote:
> I saw that mail, but I meant yet another constructor that will take an
> ISO week number and day number (within the week) and a "year"
> construct the appropriate date.
>
> Note that the year given may not be the actual year the date falls in
> but is rath
On Sat, 21 Jun 2003, Richard Evans wrote:
> I'm suggesting I donate all the DT::Locale code to the DT project next week,
> then anyone with CVS access can hack away to their hearts content - I
> wouldn't be in "control" of it any more.
>
> If you want to give me CVS access as well, that's entirely
On Sat, 21 Jun 2003, 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
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.
Well, while I was at YAPC my server crashed over and over. Whee! So I
may have missed email. If there was something that someone wanted me to
respond to, and I don't do so by next Monday or so, please let me know
about it.
-dave
/*===
House Absolute Consulting
www.houseabs
I put these on datetime.perl.org. They're linked from the resources page.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
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
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
901 - 1000 of 1439 matches
Mail list logo
