Re: The arguement for time-only.
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 string Feb 29th this year returns undef 75% of the time.
2. We can't always set the day to 31, especially in Feb
If I could return DateTime::Undef when it doesn't parse, and if set()
returned DateTime::Undef if it was out of bounds, then we can turn this
code:
$parsed = $natural-parse_datetime(Feb 29th, this year);
$parsed-set( day = 31 ) if defined($parsed);
$parsed-add(days = 12) if defined($parsed);
print $parsed-datetime if defined($parsed);
It hardly has to be this awkward.
my $parsed = $natural-parse_datetime(Feb 29th, this year);
if ($parsed) {
print $parsed-set( day = 31 )-add( days = 12 )-datetime;
} else {
# actually be forced to handle failure case, which is good!
}
I like the idea that code _breaks_ if the date can't be parsed, because
that way programmers have to include explicit paths for handling failure.
This is a _good_ thing, as it encourages better programming practices.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: The arguement for time-only.
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; Yes, this makes sense to me - but I'm into functional programming. I learned that many people find it confusing, so it is better to avoid it. - Flavio S. Glock
The arguement for time-only.
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. For example: It was 12 o'clock - we know from this the hour, minute and second but have no idea of the day, month or year. Also: It was June 25 - no year, no time, but a valid date none-the-less. Sure there's some date math we can't do with it but we can still format it. What should I do with these? Currently I'm returning -01-01 00:00:00 and subing in the parts I do know, but this is just wrong! Cheers! Rick
Re: The arguement for time-only.
* Rick Measham ([EMAIL PROTECTED]) [14 Jul 2003 08:21]: [...] For example: It was 12 o'clock - we know from this the hour, minute and second but have no idea of the day, month or year. Or whether it's noon or midnight. cheers, -- Iain.
Re: The arguement for time-only.
I vote that you assume the next valid instance of the time (e.g. if they say 4 o'clock and it is 11 PM now, assume 4AM of the following day). I believe this is what Date::Manip does and it seems to be reasonable most of the time. As another possibility (which is what I did with my obsolete version of the ISO8601 parser) is to optionally take an arbitrary DT object to use as the base and fall back to today otherwise. I also returned additional items in array context, the first was the DT object and the additional items described what was parsed so if the person cared about time only in some cases they could tell them apart from the fully specified items. Additionally I allowed the user to tell the parser what formats were valid. I don't know if that is applicable in this parser though. -ben On Mon, Jul 14, 2003 at 08:19:07AM +1000, Rick Measham wrote: 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. For example: It was 12 o'clock - we know from this the hour, minute and second but have no idea of the day, month or year. Also: It was June 25 - no year, no time, but a valid date none-the-less. Sure there's some date math we can't do with it but we can still format it. What should I do with these? Currently I'm returning -01-01 00:00:00 and subing in the parts I do know, but this is just wrong! Cheers! Rick
Re: The arguement for time-only.
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 with. I'd like to see attributes that act as a mask for which information is valid. So perhaps there would be time_only() and date_only() constructors for DT. time_only() would accept only hour/minute/seconds/tz/locale params and return an object with rd_days set to zero. Because of the attributes we could tell that date math with this object would be bogus. This could easily done as a decorator class and I'll volunteer to write it if Dave agrees. Sounds OK to me .. Oh, and while we're at it, can there be any way to set an undefined datetime object constructor: $undef = DateTime-undef(); This would normally only be used by module authors to return undef without dieing. $dt = next_datetime_after_2003_where_year_is_2000; $dt-year # month, day etc. returns undef It's kind of like an infinite +/- datetime only its .. non existant! $dt $dt_inf; # always true $dt $dt_inf; # always false $dt $dt_minus_inf; # always false $dt $dt_minus_inf; # always true $dt $dt_undef; # always false $dt $dt_undef; # always false $dt $dt_undef; # always false -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners Write a wise proverb and your name will live forever. -- Anonymous
Re: The arguement for time-only.
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; # always true $dt $dt_inf; # always false $dt $dt_minus_inf; # always false $dt $dt_minus_inf; # always true $dt $dt_undef; # always false $dt $dt_undef; # always false $dt $dt_undef; # always false Sounds reasonable to me. I'd like to know what Flavio thinks about it. -J --
Re: The arguement for time-only.
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. Unsurprisingly, I don't like this ;) My experience with SQL tells me that down the path of 3-valued logic lies madness. How is returning a weird object that looks sort of like a DateTime clearer than returning false? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
