Re: RFC: DateTime::Complex
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( time_zone/locale/year/month/etc ); # returns a formatted number or a name No, I'd rather not. That's ugly. can_set; # returns qw/time_zone locale year month etc/ can_get; # returns qw/time_zone locale year month week etc/ This is a bit ugly too. There's probably other ways to achieve what you want. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::Complex
[EMAIL PROTECTED] schrieb/wrote: I want some feedback on the API, while I write some more tests. Then I'll write the implementation. Well, I've already written some ideas about a possible API in news:[EMAIL PROTECTED]. 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 interface to the precision fields. So parsers could just return a DT::I object and calling code that does not expect partial dates would still kinda work. On the other hand, it would not be able to handle different calendars. But then, I wonder if it's possible to just build a wrapper for all DateTime::Calendar::* modules. Probably, all modules except DT::C::Julian and DT::C::Christian (which do use 'year', 'month', 'day' like DateTime) will need an own partial class anyway. Claus -- http://www.faerber.muc.de
Re: RFC: DateTime::Complex
* Claus Färber ([EMAIL PROTECTED]) [21 Jul 2003 07:31]: Claus färber [EMAIL PROTECTED] schrieb/wrote: Well, I've already written some ideas about a possible API in news:[EMAIL PROTECTED]. Note: That message is available as http://nntp.x.perl.org/group/perl.datetime/3456 Also at: http://nntp.x.perl.org/group/;[EMAIL PROTECTED] Just pointing that out for future reference =) cheers, -- Iain.
Re: RFC: DateTime::Complex
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 interface to the precision fields. So parsers could just return a DT::I object and calling code that does not expect partial dates would still kinda work. The phrase still kinda work sets of my alarms. I think parsers that can return DT::Incomplete objects need to be very explicit that they do so. In fact, we might even want to insist that parse_datetime _always_ return a complete object or fail, and then offer an additional parse_incomplete_datetime method or something like that. Otherwise people will consistly have to test the returned object's type to make sure it contains the information they need. Since for _most_ people, incomplete dates will be an error condition, I don't want to force them to deal with them. On the other hand, it would not be able to handle different calendars. But then, I wonder if it's possible to just build a wrapper for all DateTime::Calendar::* modules. Probably, all modules except DT::C::Julian and DT::C::Christian (which do use 'year', 'month', 'day' like DateTime) will need an own partial class anyway. Yeah, the idea that core code should be shareable among different calendars is mostly bogus. Ignoring the Julian and Christian modules, most other calendars are sufficiently different that they don't really match up well method-wise with the core code. Java tries to shoehorn them all into one API and it's a horrible disaster. Let's not repeat that mistake. If people _really_ need a DT::Calendar::Mayan::Incomplete, it'll have to stand on its own. OTOH, I really doubt that most calendars will need such a thing. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RFC: DateTime::Complex
RFC: DateTime::Complex use DateTime; use DateTime::Complex; use strict; my $dtc1 = DateTime::Complex-new_undef; my $dtc2 = $dtc1-define_month( 12 ); my $christmas = $dtc2-define_day( 24 ); my $december = $christmas-undef_day; print $december-datetime; # -12-xxTxx:xx:xx print $christmas-next( DateTime-now )-datetime; # 2003-12-24Txx:xx:xx my $xmas_noon = $christmas-define_hour( 12 ); print $christmas-contains( $xmas_noon ); # 1 [some too-weird examples removed] :) - Flavio S. Glock
Re: RFC: DateTime::Complex
I like the idea (this is the partial date time thing right?) but I am not too sure about the name... unless you start dealing with times with real and imaginary parts :-) (Not that I have any suggestions for a name yet). Regarding the interface would it be better to have: -- my $dtc1 = DateTime::Complex-new_undef(); # I assume that DT::C-new() assumes 0 like DT-new() # but that DT::C-new(year = 2003, day = undef ) # would give 2003-xx-01-T00:00:00? my $dtc2 = $dtc1-set( month = 12 ); my $christmas = $dtc2-set( day = 24 ); # Do these clone BTW or are $dtc1, $dtc2 and $christmas all refs # to the same object (like DateTime does)? my $december = $christmas-set(day = undef); print $december-datetime; # -12-xxTxx:xx:xx # See above question re cloning objects. print $christmas-next( DateTime-now )-datetime; # 2003-12-24Txx:xx:xx my $xmas_noon = $christmas-clone()-set( hour = 12 ); print $christmas-contains( $xmas_noon ); # 1 -- Regarding the cloning question, it is more like DateTime if they do not get cloned autmomatically, but I am assuming your implementation is based on your DT::Set which I think does clone automatically? I would still vote for not cloning. -ben On Fri, Jul 18, 2003 at 11:15:30AM -0300, Flavio S. Glock wrote: RFC: DateTime::Complex use DateTime; use DateTime::Complex; use strict; my $dtc1 = DateTime::Complex-new_undef; my $dtc2 = $dtc1-define_month( 12 ); my $christmas = $dtc2-define_day( 24 ); my $december = $christmas-undef_day; print $december-datetime; # -12-xxTxx:xx:xx print $christmas-next( DateTime-now )-datetime; # 2003-12-24Txx:xx:xx my $xmas_noon = $christmas-define_hour( 12 ); print $christmas-contains( $xmas_noon ); # 1 [some too-weird examples removed] :) - Flavio S. Glock
Re: RFC: DateTime::Complex
What were your thoughts on the constructor? I think people expect a new, but are unspecified things 0 (like DateTime) or undefined? Also, what happens when you compare dates (or is that simply not defined?). Now that I think about it, you will probably need contains, intersects, etc. But I assume you already planned that. For the name, my thoughts are: DT::Partial DT::Incomplete DT::Reduced Is it useful to have an optional base DT that can be used when an item is undefined (to more easily allow Time only objects): -- my $dtw = DateTime::Whatever-new (hour = 10, minute = 5, second = 2); my $dt = DateTime-new(year = 2003, month = 7, day = 18); $dtw-set( base = $dt ); print $dtw-year; # 2003 -- If you do that it may also be useful to have a method fix() (or get_datetime() or flatten() or something) that returns a DateTime either using the current base datetime, a provided datetime, or now() (perhaps today()). This would make it convenient as a the thing to return from formats where there can be missing information: -- ... my $dt = DateTime::Format::Whatever-parse_datetime(12:30) -flatten(); ... -- Or am I off my rocker? -ben On Fri, Jul 18, 2003 at 12:54:55PM -0300, Flavio S. Glock wrote: Yes, this is better: $dtc1-set( month = 12 ); $dtc1-set( month = undef ); It can work without cloning, in order to be compatible with DateTime API. Name - how about DateTime::Whatever ? (I like it) $date = DateTime::Whatever-whatever( year = 2003 ); # 2003-xx-xxTxx:xx:xx $date = DateTime::Whatever-new( year = 2003, day = undef ) # 2003-xx-01-T00:00:00 And this is one of the lines I snipped from the previous mail: $date-add( months = 12 ) # 2004-xx-01-T00:00:00 - Flavio S. Glock Ben Bennett wrote: I like the idea (this is the partial date time thing right?) but I am not too sure about the name... unless you start dealing with times with real and imaginary parts :-) (Not that I have any suggestions for a name yet). Regarding the interface would it be better to have: -- my $dtc1 = DateTime::Complex-new_undef(); # I assume that DT::C-new() assumes 0 like DT-new() # but that DT::C-new(year = 2003, day = undef ) # would give 2003-xx-01-T00:00:00? my $dtc2 = $dtc1-set( month = 12 ); my $christmas = $dtc2-set( day = 24 ); # Do these clone BTW or are $dtc1, $dtc2 and $christmas all refs # to the same object (like DateTime does)? my $december = $christmas-set(day = undef); print $december-datetime; # -12-xxTxx:xx:xx # See above question re cloning objects. print $christmas-next( DateTime-now )-datetime; # 2003-12-24Txx:xx:xx my $xmas_noon = $christmas-clone()-set( hour = 12 ); print $christmas-contains( $xmas_noon ); # 1 -- Regarding the cloning question, it is more like DateTime if they do not get cloned autmomatically, but I am assuming your implementation is based on your DT::Set which I think does clone automatically? I would still vote for not cloning.
Re: RFC: DateTime::Complex
Flavio S. Glock schreef: First release of DateTime::Incomplete ! http://www.ipct.pucrs.br/flavio/perl/DateTime-Incomplete-0.00_01.tar.gz It is incomplete, of course. Very much so... I would prefer if this: DateTime::Incomplete-new( year = 2003 ); would create the incomplete dt 2003-xx-xxTxx:xx:xx; that is: the defaults of the DT::I constructor should be 'unknown'. That simplifies the creation of DT::I objects, and is the most intuitive solution. I don't know what implementation you're thinking of, but I'd like to be able to say DateTime::Incomplete-new( year = 1534, calendar = 'Julian' ); Would that be easy to implement, or would I need to create my own DT::C::Julian::Incomplete modules? Eugene
