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:
> > 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 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
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 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.
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 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
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 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, 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 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 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, 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, 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:
> > 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, 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:
> 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, 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, 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 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
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, 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
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, 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:
> > 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, 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:
> 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, 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, 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 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 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, 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 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 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 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 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, 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:
> ./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 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 Thu, 17 Jul 2003, Joshua Hoblitt wrote:
> > Upgrade XML::Simple and/or maybe install the latest XML::SAX. I think
> > it's the XML parser hanging.
>
> Already upgraded both - didn't fix it. It feels like the parser has a race
> condition.
Also upgrade XML::Parser, just for fun.
-dav
/*==
Can someone tell me what the _local_ time is for TZ changes in Sydney? My
reading of the time zone file suggests that on the last Sunday in March,
at _1:00_ (AM) local time, the clock is moved one hour back, and that on
the last Sunday in October, at _2:00_ (AM) local time, the clock is moved
forw
On Fri, 18 Jul 2003, Iain Truskett wrote:
> * Dave Rolsky ([EMAIL PROTECTED]) [18 Jul 2003 12:56]:
> > Can someone tell me what the _local_ time is for TZ changes in Sydney? My
> > reading of the time zone file suggests that on the last Sunday in March,
> > at _1:00_ (AM)
On Fri, 18 Jul 2003, Iain Truskett wrote:
> * Dave Rolsky ([EMAIL PROTECTED]) [18 Jul 2003 12:56]:
> > Can someone tell me what the _local_ time is for TZ changes in Sydney? My
> > reading of the time zone file suggests that on the last Sunday in March,
> > at _1:00_ (AM)
On Fri, 18 Jul 2003, Iain Truskett wrote:
> > Hmm, timeanddate.com says this: DST ended on Sunday, March 30, 2003,
> > at 3:00:00 AM local daylight time
>
> > Implying that the change is from 3am to 2am, not 2am to 1am.
>
> > Are you _sure_ you're right for Sydney?
>
> I'm sure I'm not right.
>
>
On Thu, 17 Jul 2003, Joshua Hoblitt wrote:
> Since much of DT::TZ is being renamed how about changing
> DT::TimeZoneCatalog to DT::TimeZone::Catalog? I think it would feel a
> little more orthogonal with the other naming conventions.
Huh? None of it's being renamed.
-dave
/*=
On Fri, 18 Jul 2003, Joshua Hoblitt wrote:
> > > Since much of DT::TZ is being renamed how about changing
> > > DT::TimeZoneCatalog to DT::TimeZone::Catalog? I think it would feel a
> > > little more orthogonal with the other naming conventions.
> >
> > Huh? None of it's being renamed.
>
> You'v
On Sun, 20 Jul 2003, Claus Färber wrote:
> The most important difference is that I'd like DateTime::Incomplete to
> actually BE a DateTime: Methods defined by DateTime would just behave as
> if the base date had been set to 1970-01-01T00:00:00.00...; new methods
> (or parameters) would make up the
On Mon, 21 Jul 2003, Flavio S. Glock wrote:
> I'd like to have this in DateTime:
>
> set( time_zone => $tz );
You mean as opposed to set_time_zone?
> set( locale => $loc );
This already exists;
> get( time_zone/locale/year/month/etc );
> # returns a number or an object
>
> get_str( t
On Mon, 21 Jul 2003, Flavio S. Glock wrote:
> > We can also have autoloaded procedures like has_month(), get_month() or
> > just month().
>
> Yes, but I've seen some talk in this list, that autoloading is bad.
> Anyone has opinions on this?
Autoloading is bad, because it breaks '->can'.
If DT::I
On Mon, 21 Jul 2003, Joshua Hoblitt wrote:
> DateTime::TimeZone::Local::_from_etc_timezone needs to be modified for
> Solaris. Is there a perfered way of doing this? I can either check the
> osname then decided what path to execute or just always check for
> /etc/TIMEZONE.
The latter. I'd assu
On Mon, 21 Jul 2003, Flavio Soibelmann Glock wrote:
> has(), get()
I really dislike this API. The object should look as much like a
DateTime.pm object as possible. For other calendars, we can come up with
some clever way to auto-generate appropriate classes for them, if that's
necessary. But I
On Tue, 22 Jul 2003, Ben Bennett wrote:
> 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 number (do you usually do
> that just before release?) I need that ver
Testing on non-UNIX platforms is much appreciated. Any Mac Classic users
out there?
1.07_91 2003-07-22
- Henrik refined his edge case fix to work on Win32, which apparently
dislikes large negative signed ints. Tests now pass on Win32. More
testing on other platforms is appreciated.
- Docume
On Sun, 20 Jul 2003, Joshua Hoblitt wrote:
> Did anyone contact the author (Blair Zajac) about renaming this module?
Nope, but it'd be nice if he did.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
The existing code has some serious problems with the use of the base
datetime.
For example, the set() method will attempt to unconditionally call set()
on the base object. But if the base is 2003-02-10T00:00:00 and one calls
"$dti->set( day => 30 )" then we'll get a validation error. But if the
On Tue, 22 Jul 2003, Joshua Hoblitt wrote:
> > For example, the set() method will attempt to unconditionally call set()
> > on the base object. But if the base is 2003-02-10T00:00:00 and one calls
> > "$dti->set( day => 30 )" then we'll get a validation error. But if the
> > incomplete object on
Got some weird failures on Solaris and realized the hopelessness of
depending on external stuff.
1.07_92 2003-07-23
- Removed tests which relied on the zoneinfo database to be up to date
and accurate in order to pass, since we have absolutely no control
over this whatsoever. I hate external dep
On Wed, 23 Jul 2003, Joshua Hoblitt wrote:
> You'll have to generate the locale files from the icu-xml descriptions
> (instructions are in the dist). Or if you wait about a week DT::Locale
> will hopefully be released to CPAN (crosses arms, looks at Dave).
Poof, done.
/*===
Not terribly exciting by itself, but look for DateTime.pm 0.14 coming
soon, which will make use of this.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Well, here goes nothing ...
Still need to get to the root of the infinite number problems of Win32.
Volunteers wanted ...
0.14 2003-07-23
[ BACKWARDS INCOMPATIBILITIES ]
- The DateTime::Language modules are no longer being developed or
distributed as part of the DateTime.pm distribution.
Again, test results on non-UNIX platforms are appreciated.
1.07_93 2003-07-23
- Henrik's code explicitly didn't work with negative epoch values,
which is not good. Now we assume that they are allowed, except on
MacOS, which is known to use an unsigned int for time_t.
- Document that dates befo
On Wed, 23 Jul 2003, Ben Bennett wrote:
> I hate to say this but the language stuff may be deprecated in favor
> of locales...
>
> But if you are willing to convert this to a locale definition I would
> like to ask you about some extra stuff for my DateTime::Format::Common
> parser. But I am not
On Wed, 23 Jul 2003, Ricardo SIGNES wrote:
> Is there a good way to determine whether to not to return Unicode
> strings? That's what I'm doing now, but obviously it's not so nice at
> the console. I don't do much serious work with Unicode in Perl, and
> there might be an obvious solution I don'
Unicode is so broken in 5.6.x ...
0.1401 2003-07-24
[ BUG FIXES ]
- Fix a test failure in 13strftime.t under Perl 5.6.1 (and probably
5.6.0).
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Thu, 24 Jul 2003, Ricardo SIGNES wrote:
> What I was hoping for was a way to know whether it's useful to provide
> Unicode strings as results. In Esperanto, there are well-accepted
> conventions for ASCIIfying its Latin-3 letters. For example,
> "\x{0109}u" in Unicode would be written "cxu" i
On Thu, 24 Jul 2003, Serge Leger wrote:
> The call to DefaultLocale should only occur when it is needed (ie: just
> before actually validating the parameters). After having looked at where
> BasicValidate and NewValidate are used, I have applied the following
> changes to the new function:
Yep, t
0.1402 2003-07-24
[ BUG FIXES ]
- Fix DefaultLocale method, which didn't work at all. Reported by
Serge Leger.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Fri, 25 Jul 2003 [EMAIL PROTECTED] wrote:
> I'm trying to figure out how to allow for incomplete year/month/day,
> year/week/day, or year/day in DT::I.
>
> One way is to have a separate implementation for each case:
>
> DateTime::Incomplete
>
> year / set_year
> month / set_month
> day /
On Thu, 24 Jul 2003, Joshua Hoblitt wrote:
> I still can't get DT::Locale's parser to run under Linux (seems happy
> with Solaris thou). Has anyone else tried this under Perl 5.8.0 on
> x86/Linux?
Works for me with that exact setup.
-dav
/*===
House Absolute Consulting
www
On Fri, 25 Jul 2003, Claus Färber wrote:
> I just tried to install DateTime from CPAN but that does not work: The
> tests for DateTime require DateTime::Locale to be installed and vice-
> versa.
>
> I think the tests in DateTime.pm/ that depend on DT::Locale should be
> moved to DT::Locale.
Actua
On Fri, 25 Jul 2003, Joshua Hoblitt wrote:
> I've reinstalled just about everything applicable from CPAN. I wonder
> if it's a problem with some c library in the dep. chain.
Note that XML::Simple uses XML::SAX, which in turn picks one of
XML::Expat, XML::SAX::PurePerl, or XML::LibXML to do parsi
On Fri, 25 Jul 2003, Joshua Hoblitt wrote:
> > > I've reinstalled just about everything applicable from CPAN. I wonder
> > > if it's a problem with some c library in the dep. chain.
> >
> > Note that XML::Simple uses XML::SAX, which in turn picks one of
> > XML::Expat, XML::SAX::PurePerl, or XML:
DT::F::Strptime lists DT::Language as a prereq, which causes CPAN to try
to install DateTime 0.13 in order to satisfy it. This prereq should be
removed, I think.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Sun, 27 Jul 2003, Joshua Hoblitt wrote:
> > A while ago I proposed a patch that would add rd_nanosecs to the
> > return values from utc_r_values(). If I recall correctly, I was
> > supposed to update the calendar dev docs before applying the patch.
> > This would avoid the need for every calen
On Sun, 27 Jul 2003, Joshua Hoblitt wrote:
> > > I'm tempted to just die if both objects aren't DateTime.pm objects
> > > actually. I'd like to be free to optimize this method in the future, and
> > > I don't want to have to support other classes in it.
> > >
> > > And if there is a real need, a
On Sun, 27 Jul 2003, Joshua Hoblitt wrote:
> > Why don't you go ahead and update the calendar dev docs too. Since if
> > nothing is returned for nanoseconds it'll be zero (well, undef), the
> > transition shouldn't be a problem
>
> Should we guarantee (well specify anyways) that value passed/retu
On Mon, 28 Jul 2003, Rick Measham wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Joshua Hoblitt) wrote:
>
> > >I'd fix DT::F::Strptime but Rick won't put his code into our CVS tree.
> >
> > I meant to say hasn't - sorry Rick.
>
> Dave, if you want to add me to the CVS stuff I'll se
On Mon, 28 Jul 2003, Eric Cholet wrote:
> It isn't clear from the Changes files that the switch from Language to
> Locale also means that day and month names are now returned in utf8
> instead of latin1, at least that's what I see when using 'fr'. Am I
> correct in assuming that this change cames
On Tue, 29 Jul 2003, Jean Forget wrote:
> - The install procedure uses Module::Build. The ExtUtils::MakeMaker option
> is no longer available. There is still a Makefile.PL, but this is the
> same as in DateTime::TimeZone : this file suggests to install Module::Build instead
> (I have not tested, b
On Tue, 29 Jul 2003, Joshua Hoblitt wrote:
> I think that XSLoader isn't correctly handling the version argument -
> it's hard to tell as that is some scary code. :) I know that your not
> to blame for XSLoader but your better qualified to determine what the
> issue is then I am. Any ideas?
>
>
On Tue, 29 Jul 2003, Dan Sully wrote:
> 0.13 2003-05-05
>
> [ IMPROVEMENTS ]
>
> - DateTime now does more validation of parameters given to
> constructors and to the set() method, so bogus values like a month of
> 13 are a fatal error.
>
> I'm not entirely sure I'd call this an improvement
On Tue, 29 Jul 2003, Dan Sully wrote:
> * Dave Rolsky <[EMAIL PROTECTED]> shaped the electrons to say...
>
> > my $dt1 = DateTime->new( month => $month, year => 2002 );
> >
> > my $dt2 = $dt1->clone->add( months => 1 )->subtract( seconds =>
On Tue, 29 Jul 2003, Dan Sully wrote:
> * Dave Rolsky <[EMAIL PROTECTED]> shaped the electrons to say...
>
> > Well, obviously this is a bug in the DateTime code, as that's not what
> > _anyone_ would expect as a result, right?
>
> Just checking to make sur
On Tue, 29 Jul 2003, Dan Sully wrote:
> * Dave Rolsky <[EMAIL PROTECTED]> shaped the electrons to say...
>
> > Ah, looks like a bug in the pure Perl version of the code.
> >
> > I'll fix it and release a new version soon.
>
> That's odd. As I'm
0.15 2003-07-29
[ IMPROVEMENTS ]
- The utc_rd_values() method now returns nanoseconds in addition, Rata
Die days and minutes. Based on a patch by Joshua Hoblitt.
- The from_object() method expects objects to return the same values
from their utc_rd_values() methods. Based on a patch by Joshu
On Tue, 29 Jul 2003, Dan Sully wrote:
> * Eugene van der Pijll <[EMAIL PROTECTED]> shaped the electrons to say...
>
> > This solution, OTOH, should work:
> >
> > my $dt3 = DateTime->last_day_of_month( month => $month, year => 2002)
> > ->add( days => 1 )
> >
On Tue, 29 Jul 2003, Joshua Hoblitt wrote:
> 'DateTime' Object
> http://www.python.org/doc/2.3/lib/module-datetime.html
No leap seconds. Years 1 - only! (why?!). microsecond resolution.
> Gregorian Calendar from Calendrical Calculations that requires 'DateTime'
> http://www.python.org/doc
On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
> > - For this release, at least, the module always uses Dynaloader. This
> > is in order to see if this fixes a problem on Solaris where the
> > install library version of the DateTime .so file is loaded instead of
> > the newly compiled version in the
On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
> > > > - For this release, at least, the module always uses Dynaloader. This
> > > > is in order to see if this fixes a problem on Solaris where the
> > > > install library version of the DateTime .so file is loaded instead of
> > > > the newly compiled
0.1502 2003-07-31
[ BUG FIXES ]
- XSLoader wasn't the problem on Solaris, so it's back.
- Now loading the XS version of DateTime.pm is wrapped in an eval
block. If it fails with an error about the object version not
matching, the pure Perl version is loaded instead. This should fix
Solaris.
On Wed, 30 Jul 2003, Joshua Hoblitt wrote:
> > But why would people do that on Solaris is my question.
>
> For some reason it doesn't always identify that gcc is available (thats
> how I noticed the problem). Don't ask me why someone would install the
> XS version then switch to pure-perl. Never
On Fri, 1 Aug 2003, Eugene van der Pijll wrote:
> I've encountered a bug in DT::Infinite math. It seems that adding a
> number of days to DT::Infinite::Future results in a DT::I::Future object
> again, but adding a number of years changes it.
>
> For example:
>
> my $dt = DateTime->now;
>
>
0.1503 2003-07-31
[ BUG FIXES ]
- Adding a duration with delta months to an infinite DateTime was
quite broken. Reported by Eugene van der Pijll.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
On Fri, 1 Aug 2003, Joshua Hoblitt wrote:
> > [1] Why UTC? Wouldn't Europe/Stockholm be more appropriate?
>
> I committed this change to CVS but I think it may have uncovered some
> sort of weird bug in DT::TZ. Could you run the tests from the CVS
> version and let me know if they hang?
It's not
On Fri, 1 Aug 2003, Joshua Hoblitt wrote:
> > [1] Why UTC? Wouldn't Europe/Stockholm be more appropriate?
>
> I committed this change to CVS but I think it may have uncovered some
> sort of weird bug in DT::TZ. Could you run the tests from the CVS
> version and let me know if they hang?
I take i
On Fri, 1 Aug 2003, Flavio S. Glock wrote:
> > That's going to take a while. I'd recommend using a year a little closer
> > to our own. DT::TZ ships with the changes pre-generated 30 years out, so
> > dates in that range are quick. Dates within a couple hundred years out
> > aren't too bad eith
On Fri, 1 Aug 2003, Claus Färber wrote:
> Dave Rolsky <[EMAIL PROTECTED]> schrieb/wrote:
> > That's going to take a while. I'd recommend using a year a little
> > closer to our own. DT::TZ ships with the changes pre-generated 30
> > years out, so dates in
On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
> > $dt = DateTime->now_high_res();
> > or
> > $dt = DateTime->now( high_res=>1 );
>
> Thats a possibility too. Although to me that syntax would seem to
> guarantee HiRes support to be available. I don't know if we want add
> Time::HiRes as a dependency.
On Sat, 2 Aug 2003, Claus Färber wrote:
> Joshua Hoblitt <[EMAIL PROTECTED]> schrieb/wrote:
> >> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call
> >> would work without adding HiRes as a dependency.
>
> > It does - ...
>
> IMO no DateTime::* module should depend on Time or Date mo
On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
> > In general, I have no qualms about dependencies if they're on
> > known-to-be-good modules _and_ they provide some useful functionality. In
> > this case, it's even less of a concern since Time::HiRes is a core module.
>
> We can't import Time::HiRes'
501 - 600 of 1439 matches
Mail list logo
