Re: DT::Duration::Set
Dave Rolsky [EMAIL PROTECTED]: Can you and/or Joshua explain what this would be used for? elbowing in Unbounded clocks? Matt
DT::*::ICal modules
Dave: I think it would be good to integrate DT::Event::ICal, DT::Format::ICal and DT::Set::ICal in a single distribution. This would make it easier to manage dependencies and version checking between them, and we would have a single, comprehensive test suite. It would make it easier to install, too. - Flavio S. Glock
Re: DT::Duration::Set
Maybe there is something fundamental we can boil out of DT::E::R. hmmm... I found out a way to get a duration-set out of DT::E::R: $dt_set = new DT::E::R( %param ); # datetimes $dur_set = $dt_set - $dt; # durations! It will not work under the current implementation, but it can be done. - Flavio S. Glock
Re: DT::Duration::Set
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
Re: DateTime::Format::ISO8601 namepsace
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 new version was sent to CPAN last night. A road-map was sent to the list along with the release. Basically the next release will be bug fixes and more tests - hopefully a thousand or more new tests. Then the ISO section 5.5 stuff can be started on. 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). Sorry, I skipped over that message. I dug it up and read it. I have some additional functionality that I think is critical: 1) The ability to say which pieces of the ISO spec are applicable (otherwise you can not tell the formats with leading -s apart from the ones with expanded years). Also you need to be able to specify the number of additional years 2) Return information about the matching format so that you can tell which information is ommitted in the reduced formats. (e.g. I want to be able to tell the year 2003 apart from Jan 1 2003. Then some other information that would be nice: 3) Return the parts of the string that matched (in addition to 2 above, this makes handlind reduced formats more pleasant, rather than having to infer the week number from a returned DateTime). 4) The ability to specify an arbitrary base date for the implied computations and times I also think you will need 3 to support durations that have the form of a date (especially since they may not be valid dates if parsed by DateTime, e.g. P0002-02-30, for a duration of 2 years, 2 months and 30 days). Bugs that I have noticed: a) The parser allows partial extended form on the times, so it takes 12:3000... b) It does not allow all combined date and time formats that are legal (any non-truncated date and any non-reduced time combination is legal), also the whole expression must be either entirely in basic or expanded form (not mixed) c) Your fractional_hour does not compute seconds and nanoseconds (i.e. T10.412342 gives precisely 10:24:00) d) Your parse_time only parses the ambiguous time formats, some time formats are only in parse_datetime Other issues (that I didn't solve either): i) You assume that a minute is 60 seconds in the fractional code ii) For fractional durations, how do you represent .3 of a month? (The best answer I could come up with was to use the base date or today to get the number of days in a month). By collaborating with Iain while working on my ISO parser many very useful features have been incorporated into DT::F::Builder. I'd like to continue along this path as it has potential benefits for other authors. Of course your help is welcomed. Sure, but how much further is it worth bending DT::F::Builder to handle this finicky standard? As I've said from the beginning I think your parser is very interesting and I don't want to see you abandon it. Perhaps it should be extracted from the ISO8601 specific stuff and rolled into a stand alone module for specifying date/time formats. Maybe DateTime::Format::Grammar? I honestly don't think it is usefull outside of the context of ISO8601, it has a lot of the odd ISO stuff baked into it and if you were to do a generic Grammar then DT::F::Builder is a simpler base (unless you need lots of odd semantics in which case it is probably better to roll your own). -ben
Re: DT::Duration::Set
Can you expand on this please? 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 can be compared to other clocks (for example, compare interval lengths). All the talk about duration sets, plus some earlier talk about time-only datetime objects, sounded like these concepts had a lot in common with clocks. (perhaps I'm just odd) Matt
Re: DT::Duration::Set
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 can be compared to other clocks (for example, compare interval lengths). A while back I posted a DateTime::Time module that was basically an unbounded clock. It didn't go down so well. Maybe some of the stuff in the docs wasn't right, but still it was useful. Basically the biggest changes I'd make to it now would be to edit the overloads so that if someone added the object to a bounded datetime it would return a bound datetime. (Maybe it already did .. can't remember) and I'd do the same with set(). Once we got an actual date, the clock would be bound. Currently we have no way of creating a time, or unbounded datetime. I imagined that such a clock would think of minutes as 60 seconds and days as 24 hours. Despite leap-seconds and leap-years. Without a date we have no idea when they occur. The difference between a Duration and a DateTime::Time is that a duration thinks of itself in terms of its contructors. It is an array of days, hours, etc.. A DateTime::Time would probably be a Calendar where all things are normalised. In my implementation it thought of itself as a number of seconds. The other difference was in the API. DateTime::Time uses the same API as DateTime herself. This aids in understanding. I'd even go so far as to suggest that DateTime::Time should be invisible. Create a DateTime without a Date and you get back a DateTime::Time object until such time as you provide enough information to be able to bind it. I can still hear people saying 'But why?'. Well the answer is because people don't think of times as bound by default. When your wife asks you what time it is you look at the clock on the wall. The time there is unbounded. You don't say It's 9:47 am, but only because it's the 6th of July 2003. Many database implementations (including the SQL92 standard AFAIK) have a time-only column type. What do we do with these? At the moment if I come across something like this I return -Jan-00. But that's silly. They didn't mean that when they set the time. They just didn't tell me when it was. Why not? because they didn't care. Maybe they have a log file for July 6th but from the log there's no way of knowing it's July 6th. All we know is that each entry has a time. We can't DateTime it. However we should be able to. We should still be able to access it using the same calls we use for bound times. We should be able to format it and manipulate it and add to it the same way. /rant Cheers! Rick
Re: DT::Duration::Set
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 can be compared to other clocks (for example, compare interval lengths). A while back I posted a DateTime::Time module that was basically an unbounded clock. It didn't go down so well. Maybe some of the stuff in the docs wasn't right, but still it was useful. It wasn't that it didn't go down well, I just couldn't understand what it was for. This was largely because the docs compared it to DT::Duration, but were wrong in several cases about what they said re: DT::Dur, so I couldn't tell if it solved an actual problem! I can still hear people saying 'But why?'. Well the answer is because people don't think of times as bound by default. When your wife asks you what time it is you look at the clock on the wall. The time there is unbounded. You don't say It's 9:47 am, but only because it's the 6th of July 2003. Many database implementations (including the SQL92 standard AFAIK) have a time-only column type. What do we do with these? But of course, you do _know_ (in theory ;) that it's July 6th. And if someone tells me something will occur in 60 seconds, the fact that I _don't_ know the date doesn't change the fact that those 60 seconds might include a leap second ;) Maybe they have a log file for July 6th but from the log there's no way of knowing it's July 6th. All we know is that each entry has a time. We can't DateTime it. However we should be able to. We should still be able to access it using the same calls we use for bound times. We should be able to format it and manipulate it and add to it the same way. I guess my assumption is that the end user _must_ know what date a time is associated with, even if they don't save that in the DB. Anyway, what I'd _really_ like to see is some actual application code that uses your proposed module. I'm really not violently against it, I just want to see how you would use it in an app. People keep proposing interesting ideas, but unless they also say here's X different real-world application uses, I'm going to keep vetoing them ;) It's great that there's so much interest in the DateTime project, but that means my most important role has changed from person who implements core stuff to person who tells everybody 'No' so project doesn't explode into a ridiculously complex, unusable mess. I take this role seriously, and I'm very leary of adding new core objects/classes without very good reason. Every new core object requires lots of docs, more FAQ entries, and more explanation on this list, not to mention more slides in my presentations ;) Note, I'm not saying you don't have them, I'm just saying that _I_ don't understand them (yet?). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::ISO8601 namepsace
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 pieces of the ISO spec are applicable (otherwise you can not tell the formats with leading -s apart from the ones with expanded years). Also you need to be able to specify the number of additional years The simple solution is parse_time - a better one is coming. 2) Return information about the matching format so that you can tell which information is ommitted in the reduced formats. (e.g. I want to be able to tell the year 2003 apart from Jan 1 2003. I agree but we don't have attributes for DT yet. Then some other information that would be nice: 3) Return the parts of the string that matched (in addition to 2 above, this makes handlind reduced formats more pleasant, rather than having to infer the week number from a returned DateTime). Return how? 4) The ability to specify an arbitrary base date for the implied computations and times I agree with this. But what is there now works well... I also think you will need 3 to support durations that have the form of a date (especially since they may not be valid dates if parsed by DateTime, e.g. P0002-02-30, for a duration of 2 years, 2 months and 30 days). Invalid dates should raise an exception. I'm not sure what to do about the longer then 1 year problem. My thinking is a DT::Duration::Set with multiple durations but the whole thing is fuzzy right now. Bugs that I have noticed: a) The parser allows partial extended form on the times, so it takes 12:3000... But it is matched as 12:30:00. I know about this one - It's because there isn't a forward look ahead in the regex. The fix is coming. b) It does not allow all combined date and time formats that are legal (any non-truncated date and any non-reduced time combination is legal), also the whole expression must be either entirely in basic or expanded form (not mixed) This is documented in the pod. DF::F::Builder will probably need to be changed. c) Your fractional_hour does not compute seconds and nanoseconds (i.e. T10.412342 gives precisely 10:24:00) Hmm... I'm not sure that this is wrong. The spec is kinda vague. d) Your parse_time only parses the ambiguous time formats, some time formats are only in parse_datetime This is the same as your point #1. Other issues (that I didn't solve either): i) You assume that a minute is 60 seconds in the fractional code ii) For fractional durations, how do you represent .3 of a month? (The best answer I could come up with was to use the base date or today to get the number of days in a month). Sure, but how much further is it worth bending DT::F::Builder to handle this finicky standard? A lot. :) This isn't the only weird standard. As I've said from the beginning I think your parser is very interesting and I don't want to see you abandon it. Perhaps it should be extracted from the ISO8601 specific stuff and rolled into a stand alone module for specifying date/time formats. Maybe DateTime::Format::Grammar? I honestly don't think it is usefull outside of the context of ISO8601, it has a lot of the odd ISO stuff baked into it and if you were to do a generic Grammar then DT::F::Builder is a simpler base (unless you need lots of odd semantics in which case it is probably better to roll your own). I don't think you could write a Date::Manip replacement in DT::F::Builder yet. Your parser would be pretty good for this. -J _-
