> The root of the collisions is the arbitrary number of extended digits
> (which may be 0, so you could have -0101, now is that the year 102
> BC, or January in 2001? The extended formats also collide internally,
> i.e. what is the date +1985? Is it a century or a year?
That document is a disast
Hi Dave,
I noticed that the fractional_second method is still in CVS. Is this going to be
dropped as well?
I took a look at changing utc_rd_values to support nanoseconds and it doesn't look
like much needs to be changed.
Calling _normalize_nanoseconds in the contructor certainly makes life ea
> I am running the CVS versions of DateTime/DateTime-TimeZone for perl 5.6.1
Hi Ron,
I don't claim to know anything about perl on win32 but I'm wondering if there is any
difference in warnings under 5.8.0. Is it possible for you try this?
-J
--
> It looks like the Jalali calendar is also called the Persian calendar,
> so DateTime::Calendar::Persian is a possibility too. I'm not familiar
> with this calendar, its most common name, and the way it is used, so you
> (Ahmad) should judge for yourself what name would be best.
In Calendrical Ca
> That's why I can't tell what the correct name would be for this
> calendar, (and why you can't either, I presume). Ahmad is hopefully more
> familiar with how the calendar is used today.
It's important that it's name is meaningful to potential users. We'll just document
that we decided Jalali,
> Ahmad Anvari schreef:
> > I would suggest registering DateTime::Calendar::Jalali
> > for now.
>
> If that's what most potential users would recognize, it's the right
> name. I wouldn't have recognized it, but I'm not the intended audience.
> (But I'll install it anyway...)
We could also put in a
> I don't know if I will manage to finish this thing, it is a bit of a
> monster.
Thats what happened to me. :)
-J
--
> I put these on datetime.perl.org. They're linked from the resources page.
This is a great primer to some of the issues in time handling. It'd make an
interesting talk even with out all the bits about programming.
Btw - Is anyone headed to OSCON?
-J
--
> > I was thinking about DateTime::Format::ISO8601... unless you have laid
> > claim to it.
This is the namespace I started on in March but whatever does ISO8601 should go there.
> Perhaps one of you should add it to the CVS server as-is and both work
> on it?
I haven't worked on this since the
> I haven't worked on this since the beginning of April. I believe this is most of
> the date specifications - not including the week formats. Week and UTC offset
> handling, time formats, and date + time formats are left (actually shouldn't be that
> bad). Although I don't remember why I sto
As I'm thinking about normalizing week + day numbers to month + day numbers I'm
wondering if there shouldn't be a module for all such common (to DT modules)
conversion functions? Comments?
-J
--
> There's been a lot of discussion about it which I unfortunately couldn't
> follow. Now it's up to 0.04 and seems to have a lot of functionality, and
> I really don't see the point of all of it. And even worse, it's gotten
> _more_ intimate the with DT::TZ internals, instead of less.
There was
> > Btw - Is anyone headed to OSCON?
>
> I'll be there. There's also a Perl datetime BOF scheduled for Thursday
> night from 8-9.
Theres a pdx.pm meeting on Wednesday from 7-10 if your interested.
I'm actually from Portland and arriving on the 27th of June if anyone wants to get
together before
> What will happen is end users find errors in the locale stuff, report it to
> DateTime or me, it gets forwarded to OpenI18N, who may or may not apply it
> when they feel so inclined - we'll have to wait like mugs, and users will get
> p*ssed off by the slow turnaround.
I agree with you here but
> which opens Friday night? Is there a decent movie theatre downtown?
Theres several - but wouldn't you rather be in a theater you can drink in? (and has
brewery and a distillery on site)
This is as far forward as their schedules are posted:
http://www.mcmenamins.com/Theaters/?theater=All&vie
On Fri, 20 Jun 2003, Ben Bennett wrote:
> 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 b
> I can't think of any other usage which necessitates such a constructor.
strptime needs it.
-J
--
On Sat, 21 Jun 2003, Iain Truskett wrote:
> * Ben Bennett ([EMAIL PROTECTED]) [21 Jun 2003 14:18]:
> > I have made my rough ISO8601 parser available at:
> > http://www.limey.net/~fiji/perl/DateTime-Format-ISO8601-0.01.tar.gz
>
> Could you check it into the CVS please?
A name needs to be settled
> I'm inclined to say completeness is more important than speed in this
> case. Optimizations can always be done later anyway.
They'll both be complete for Date + Date and Time formats. Just times can't be done
with DT. The difference is in supporting recurrences, durations, and the user being
> There is a DateTime->from_day_of_year constructor.
In the CVS version - what is the ETA for the next release?
-J
--
> You'll be happy to know that I will apply this for the next release,
> because it looks like it'll be a little while longer before DT::Locale is
:)
-J
--
> On Sat, 21 Jun 2003, Bruce Van Allen wrote:
> > 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.
I'd suggest that someone runs this like
> > 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 the rest.
Everything thats there (and it is pretty s
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.01.tar.gz
This is the code I'm expecting to become DT::F::ISO8601::Simple or the the like.
supports all the ISO8601 date, time, and date + time formats
expanded formats are support with a fixed 6 digit year
Please see the
I forgot to add that it's dependant on the CVS version of DT.
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.01.tar.gz
>
> This is the code I'm expecting to become DT::F::ISO8601::Simple or the the like.
>
> Dave Rolsky schreef:
> > It's really hard for me to think of a case where you would not know the
> > expected precision in advance.
It's usually true that you do know the precision in advance (not always) but not ALL
handling of time involves knowing the year.
On Sun, 22 Jun 2003, Eugene van
Should I add the namespaces doc to web/htdocs/developer/?
-J
--
> Users would just do something like:
>
> if ( DateTime::TimeZone::is_olson_timezone('foo/bar') ) { ... }
I don't like having olson in the name as this won't have much meaning to most users.
> which to me makes more sense than asking the alias module if it is an
> actual timezone.
Your not most
> A little voice has been saying that ever since I saw that Alias was
> reaching into the TZ aliases directly.
There's a warning about this in the pod. :)
-J
--
Dave,
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
preserved in a conversion.
Changes like thi
> Actually, I saw this but couldn't figure out how it differed from the
> existing code, at least in the from_object method.
It really doesn't - I just wanted to throw out the call to nanoseconds as that makes
support optional (and I don't think it should be).
> We should probably update the dev
Is anyone interested in me putting this in shared CVS? If so under what name?
Cheers,
-J
--
On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
> I forgot to add that it's dependant on the CVS version of DT.
>
> On Sat, 21 Jun 2003, Joshua Hoblitt wrote:
>
> > http://kolea.ifa.
> I've just checked some experimental code into CVS. Take a read of
> t/dispatch.t and lib/DateTime/Format/Builder/Parser/Dispatch.pm (damn
> these paths are getting long).
>
> Something like that?
Wow - Yes. The possibility for recursion is just Evil{TM}. I'm really really
impressed with the
> If something is of a static length, use lengths.
Say I have the years 2003 and -2003. In order to use static lengths I need to have
two separate regexs, /(-\d\d\d\d)/ and /(\d\d\d\d)/. If I have a lot of rules that
need to match both negative and positive years group tags can cut the worst c
Jaw drops...
> Your wish is my small patch.
I seem to have stumbled onto a new programming paradigm. I partially think through
half baked design concepts then Iain not only throughly cooks my ideas he writes all
the code. This is called Extreme Spoon Programming (xSp) - look for my upcoming
On Wed, 25 Jun 2003, Ben Bennett wrote:
> On Wed, Jun 25, 2003 at 06:53:10PM +1000, Iain Truskett wrote:
> > * Joshua Hoblitt ([EMAIL PROTECTED]) [25 Jun 2003 17:59]:
> >
> > > But what if I use /(-?\d\d\d\d)/ as the regex and set the
> > > length =>
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 to be tried is substantial.
You can mix length with no-length specrefs.
> The other thing that my
If I understand where you were going with this you want to distill the RD parts out of
DT and DT::Duration. I wouldn't mind seeing this if DT used these base classes
itself. As I'm a little concerned about the long term modularity of DT.
I doubt this will happen because of all the overhead tha
> 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.
> I'm really not sure how far (if at all) we should go in trying to make
> DateTime
> It can be broken up into multiple pieces. I certainly don't object to
> that.
Sounds reasonable.
> I'm really not convinced that subclasses should be using DateTime's new()
> method. Especially not a subclass for a calendar that has 13 months!
Well it worked because I redefined some of the s
Available immediately from:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.02.tar.gz
This is the code I'm expecting to become DT::F::ISO8601::Simple or the the like.
Changes for 0.02
0.02 Thu Thu Jun 26 22:44:38 HST 2003
- deps updated to DT 0.13 and DT::F:B 0.74
I don't recall anyone working on this.
> my $ics = new DateTime::ICS;
>
> $ics->parse( file => 'holidays.ics' );
If you really want to parse files please make it so you can pass in a file-handle and
not a filename. Also it'd be a lot more useful if you could pass in a string or array
as we
Hello,
I received this bug report on one of my modules. Is this a known problem with
Module::Build or nmake?
Cheers,
-J
--
-- Forwarded message --
Date: Fri, 27 Jun 2003 10:15:15 -0700
From: "Hill, Ronald" <[EMAIL PROTECTED]>
To: 'Joshua Hobli
> 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
> "./Bui
Are you in town yet? I've instigated a pdx.pm GT either Tues. or Weds. of this week.
-J
--
Dave,
I just noticed your on MJD's lightning talk list for OSCON. What are you going to
cram into 5 minutes? :)
-J
--
> I'm just starting to panic that I am not going to be able to survive with just a
> P233 notebook with a 56k modem when I am used to a 1.2GHz w/768k DSL. ;~) I've
> got a bunch of programming I want to accomplish next week and I don't want to be
> hampered by poor connectivity...
I'm in the same
On Mon, 30 Jun 2003, Matt Sisk wrote:
> > Documented or not, it'll never be intuitive, which makes me think it's a
> > bad idea.
>
> This could be a feature of the problem space rather than implementation. :)
>
> I'd say it's safe to say 99% of non-temporal geeks underestimate the subtle
> complex
> 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.
>
> This is not too difficult to implement.
> Is it too confu
> Ok, this is wack. When I ask the object for "delta_days" or just "days"
> what is it going to give me?
Uhh... the same thing it always has? Maybe I'm missing your point. We're talking
about overloaded operators returning another duration object. Why would that change
the return of methods?
> > How about a DT::Duration::Set class?
> >
> > add() pushes a duration object into a DT::D::Set object
> >
> > _collapse() would call a 'sum' method on a DT::D::Set object
> >
> > _collapse_to_datetime() would call _collapse (or the 'sum' method
> > directly) on a DT::D::Set object and add the re
This question has crossed 3 lists that I'm on in various forms (datetime, pdx.pm,
plug) and probably a few others. Maybe an out of town geek page would be a good idea?
I'd volunteer to do it but I count as out of town now. :)
Things to list:
hotels with connectivity
links to the freenode/pers
Looks good Ben. The timezone stuff must have been fun. :)
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 the benchmarks to the list. I'll do it
as soon as I'm back on a fast connection.
> Sometime I want to f
> Try http://oscon.kwiki.org/ .
That's just for OSCON - I'm thinking in the general case.
> We should get this name thing resolved so we can get both modules
> committed and up on CPAN. I don't care either way.
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::Si
> Is there any reason it can't all go in one module? I think that'd be much
> easier for end users.
Yes. Ben and I have discussed this off list. In fact that discussion is, I believe,
where the DT::F::DateManip module came from. I started on this several months ago and
never got around to fi
> My module is a superset of Joshua's... however, mine still needs the
> interface to be polished (I plan on adding a way to select which
> optional pieces of ISO8601 are legal).
Hmm... I could use your module for recurrence and duration parsing.
-J
--
I've resolved the last known bug my ISO8601 parser and I believe it is ready for CPAN.
Unless I hear an objection I'm going to use the DateTime::Format::ISO8601 namespace.
I'm not claiming that this is the right namespace to use but the indecision needs to
be settled. If this turns out to be
> Probably for unambiguous cases we should just allow:
>
> $iso->parse_datetime($string)
I did that.
> For more complex cases we can do:
>
> $iso->parse_datetime( datetime => $string,
>... # extra params
> )
I went with $iso->parse_time as the 6 amb
> 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.
-J
--
> Joshua, why don't you check yours into CVS as DT::F::ISO8601, release it,
> and then you and Ben can merge in all the extra functionality from Ben's
> module.
I wanted to dump it into CVS long ago but the namespace issue never cleared up.
I'll try to get my laptop online tonight to make a CPAN
> We could use a DT::Duration::Set module for things
> like "once a week for 3 weeks"
That would be ideal.
> How is that different from an ICal recurrence?
> Do we need a DT::Event::ISO8601 ?
I've been thinking about this for a few days. I don't think that DT::Event::ISO8601
would be useful on
> 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.
-J
--
> So is there any conclusion here? Should I commit my module or will
> Joshua commit his?
I thought there was a conclusion...
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.
A new version was sent to CPAN l
> Of course, this will not allow for duration-recurrences.
Aren't recurrences basically a set of durations at fixed intervals? Could duration
sets mimic the DT::E::Recurrence API? Then you could iterate from a start time until
the end of the set (would have to look for some sort of flag return
> 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.
-J
--
I want to preserve the revision history of my tree so the move to SF won't be until
next week.
What really needs to be done is a lot more tests. I'm considering a framework for
building tests.
> I have some additional functionality that I think is critical:
> 1) The ability to say which piece
> Ok, I can try to port over my framework when your code is checked in,
> although it relies on being able to pass in a base date and be able to
> select the return classes so I am not sure how easy it is to do.
I've been using now because I'm not creating parser objects. It simple enough to make
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. As soon as a namespace
is agreed upon I'll move this
> If someone knows of something on CPAN for this, please tell me. There is
> Class::Decorator, and maybe that plus a little syntactic sugar might be in
> order, so we can do:
Or we could make our own with Hook::LexWrap/Class::Hook. I don't think any of these
will work well with Memoize as it's
> Class::Hook isn't quite right, since it's about catching method calls for
> _non-existent_ classes. Hook::LexWrap isn't right either, because it
> wraps _all_ calls.
Well I was thinking that Class::Hook could catch calls to 'classes' created by
DT::Wrapper or DT::Wrapper would inherit from DT
On Mon, 7 Jul 2003, Flavio S. Glock wrote:
> How can I use this with DT::Set?
The objects created are isa DT so I would expect from_datetimes to work. What did you
have in mind?
> Does it handle add_duration() ?
Run the 0.13 tests and see what explodes. :)
-J
--
> I'm working with DateTime::Format::Natural and I really need a time-only
> object. In fact I need an object that lets me chose what I want to give
> it.
Hi Rick,
I do agree with the need for the _ability_ to handle just times but I don't think it's
worth the hassle of another class to deal wit
> 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.
> It's kind of like an infinite +/- datetime only its .. non existant!
>
> $dt < $dt_inf; # alw
> > If Dave OKs this it should be a separate class. Probably DT::Undef.
>
> If Dave OKs? Does that ever happen. Unsurprisingly, I don't like this ;)
It's never happened before but I keep hoping... :)
> My experience with SQL tells me that down the path of 3-valued logic lies
> madness.
There
> Thinking about it now, it would make the most sense to me to make
> DateTime::Format be an actual class which would dispatch to the DT::F::something
> modules. That way, nothing needs to be added to the DateTime class itself, if
> you never need parsing.
Not all of the format modules will deal
> > Great, but the $64K question is: do we then get parse() and parser() methods
> > in DateTime, which default to use DT::F::Simple? :)
>
> Maybe. It would introduce another dependency for DateTime.pm, but OTOH
> it's a dependency that most folks would probably end up downloading
> anyway.
I'm n
> 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.
-J
--
> > > 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, since it's supposed to handle
> Well, there are only two modules: DT::F::MySQL and DT::F::Pg.
I'd really like to see a lot more database formatters.
I'm willing to do DT::F::DB2.
That still leaves several major DB's unsupported:
Oracle
SQL Server
Sybase
And all the minors:
mSQL
SQLite
InterBase
Pheonix
SAPs DB
Access???
> Actually, DT::Undef is just a special case of the proposed DT::Partial
> object.
Not really - it's totally different state. Any partial time can already be expressed
with the current DT class. We just need a means to specify the precision.
-J
--
> By puking all over them right then and there. While a "DT::Undef" object
> might be useful for some, it should not be used as a return value in the
> case of an error. People who want to use it can just do this:
I agree. I specifically DON'T want DT::Undef to be returned as an error condition
> 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 ;)
Your right - I'd been traveling for 24 hours. :)
-J
--
> 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 see DT::F::X be isa DT::F::Pg.
Otherwise things mig
> Infinite dates do not exist. (And neither do undefined ones.)
If you accept that as dates or not, they are both valid pieces of information that
need to be expressed.
-J
--
In a thread long ago we'd had discussed the possibility of breaking up the DT
constructor(s) to be a little more friendly to sub-classing. Specifically so the
validation behavior could be modified. Here is an example of changes to new() to
allow this. What do you think about something like th
> 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.
I never have been in favor of the base module returning these. I'm just pointing out
that there is a niche
> The Loch Ness monster exists. That doesn't mean that
> DateTime::Format::Roman should accept it.
Yes it does. It should accepts Dave's organic cucumbers too.
-J
--
> 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.
-J
--
> Also upgrade XML::Parser, just for fun.
cpan> i XML::Parser
Strange distribution name [XML::Parser]
Module id = XML::Parser
DESCRIPTION Flexible fast parser with plug-in styles
CPAN_USERID COOPERCL (Clark Cooper <[EMAIL PROTECTED]>)
CPAN_VERSION 2.31
CPAN_FILEC/CO/COOPERCL/
> However, I didn't realize that DT::TZ::Alias didn't allow you to alias
> a name to an offset. I think that is an important feature. (Although
> you probably should not be allowed to have an alias with a name that
> looks like an offset...).
I hadn't really thought about it either. The next re
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.
-J
--
> > 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've renamed a lot of variables. :)
-J
--
> I don't really see a strong reason to rename the module.
It just feels inconsistent to me. It'll be easier to rename now then after someone is
using it.
-J
--
Did anyone contact the author (Blair Zajac) about renaming this module?
-J
--
> But there's a conflict between several expanded formats:
> ±_C_CCYYMMDD (>= 9 digits)
> ±_C_CCYYDDD (>=8 digits)
> ±_C_CCYY (>= 5 digits)
> ±_C_CC(>= 3 digits)
> unless you specify the number of digits used for the year/century.
The judgment call I've made for DT::F::ISO8
Released to CPAN.
Available immediately from:
http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-TimeZone-Alias-0.05.tar.gz
Changes since 0.04
- floating, local, UTC, Z, and offsets can now be aliased
- docs updated
Cheers,
-J
--
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.
-J
--
-- Forwarded message --
Date: 21 Jul 2003 11:37
Can anyone with a Solaris system get this to fail? I've tried it on a number of
Solaris 8 systems (the same at the smoke test) and the local time detection code is
working. I'll add support for /etc/TIMEZONE anyways but I'm wondering if it's a
specific problem with the smoke-box.
-J
--
> ---
> > 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 to see it.
>
> Sure, go ahead, but make it "date_parts_order". It'll be public, after
> all.
And I need it for DT::F::DB2 as DB2 is locale sensitive.
-J
--
101 - 200 of 394 matches
Mail list logo
