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: DateTime parse(), parser()
Hi John Iain 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 that recognizes the sorts of dates you come across. I mostly I think an example of this type of thing needs to go into the FAQ. Do you have an example of doing this? come across HTTP, W3CDTF and RFC2822 dates so I'm all set =) Sure, but my main point is that I don't want to have to manually load and use parsers. I want DateTime (the class and/or individual objects) I agree with you on this. I feel that there should be a default simple parser within datetime. have a catch-all parse() method that uses the parser class of my choosing. And I want the default to be something than can handle most normal date formats, ignoring as much complexity as it takes to get into the core (even though DateTime::Format::Simple would still be its own module, and might not even be loaded until the first call to parse()) However, I'm interested in seeing your regex to see if you parse anything that might be of use to me. Would you like to share? They're super boring. Heck, these two cover almost everything I'm interested in: [snipped] Really, I'm not asking for the moon. The key features are the built-in/used by default nature and the I can handle whatever parse() method (instead of parse_date(), parse_datetime(), parse_year_and_day_but_not_month(), etc.) Since this is all so simple, I think it should be built in via the creation and default use of a DateTime::Format::Simple module and a generalized parse() class/object method for DateTime. [much snippage] John, Can I encourage you to put together a Format::Simple module and release it? I think we need something out there for very basic date parsing. There is the DateTime::Format::HTTP that comes very close ( It works great on Ingres dates/times). Or maybe the regrex that you provided can be incorporated into HTTP? What do you think? Ron Hill
Re: DateTime parse(), parser()
On 7/14/03 12:36 PM, Hill, Ronald wrote: Can I encourage you to put together a Format::Simple module and release it? I think we need something out there for very basic date parsing. There is the DateTime::Format::HTTP that comes very close ( It works great on Ingres dates/times). Or maybe the regrex that you provided can be incorporated into HTTP? I'd gladly release the DateTime::Format::Simple I whipped up, but only if there is consensus about the scope of the module and the name ::Simple. Mine is really ::DeadSimple :) I suspect someone else out there might want to use the ::Simple namespace for something slightly less simple than the handful of regexes and constant strings I posted earlier. Opinions? 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 produce... -John
RE: DateTime parse(), parser()
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 that recognizes the sorts of dates you come across. I mostly I think an example of this type of thing needs to go into the FAQ. Do you have an example of doing this? Actually, it probably belongs directly in the Builder docs. Can I encourage you to put together a Format::Simple module and release it? I think we need something out there for very basic date parsing. There is the DateTime::Format::HTTP that comes very close ( It works great on Ingres dates/times). Or maybe the regrex that you provided can be incorporated into HTTP? 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 ;) I know Graham Barr will be happy to see this, because at OSCON he asked me when the DateTime project will make his TimeDate stuff obsolete ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime parse(), parser()
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 the $64K question is: do we then get parse() and parser() methods in DateTime, which default to use DT::F::Simple? :) -John
Re: DateTime parse(), parser()
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 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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime parse(), parser()
John Siracusa wrote: Great, but the $64K question is: do we then get parse() and parser() methods in DateTime, which default to use DT::F::Simple? :) A while ago, when this discussion last reared its [ugly] head, I suggested that the base class contain methods which would call an array of potentially more expensive parsers, until one returned a value other than undef. The default install would only include the smallest, fastest parser and the user could add other to the list. 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. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: DateTime parse(), parser()
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 with ambiguous cases in the same way. This sounds dangerous and error prone. -J --
Re: DateTime parse(), parser()
On Monday, July 14, 2003 John Peacock wrote: John Siracusa wrote: Great, but the $64K question is: do we then get parse() and parser() methods in DateTime, which default to use DT::F::Simple? :) A while ago, when this discussion last reared its [ugly] head, I suggested that the base class contain methods which would call an array of potentially more expensive parsers, until one returned a value other than undef. The default install would only include the smallest, fastest parser and the user could add other to the list. 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. Some good ideas are converging here. Couldn't the following all be possible: 1. DT::Format as an actual class, per John S; 2. DT::Format has parse() and parser() methods; 3. DT::Format dispatches to DT::F::XXX modules, using DT::F::Simple unless the user has called parser(). 4. DateTime also has methods parse() and parser(), per John P, which simply invoke DT::Format and hand off their params to DT::F's own parse() and parser() methods; 5. If the user doesn't call parse() or parser() from DT, then DT::F and DT::F::XXX are never invoked by DT; 6. All parsers fail (return undef) if they can't parse a string, both for good programming practice and to allow falling through to the next specified/available parser module; 7. parser() -- or parsers()? -- would let the user specify which of the available DT::F::XXX modules to use, and the order with which they are tried. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: DateTime parse(), parser()
On 7/14/03 2:31 PM, John Peacock wrote: Joshua Hoblitt wrote: I'm not really excited about this proposed feature. If it is included the loading of DT::F::Simple should be deferred until parse_datetime is called. 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; as well. The latter use would then take an array of additional Format modules to use when parsing (if desired). Why not have them at all? Okay, so defer parser class loading until the last minute. Then all you have is a dozen or so more lines of code in DateTime. Is that going to kill you? :) I think this is a very important feature. If DateTime didn't have strftime() already, then maybe I'd buy the argument that DateTime is just an object representation of dates and doesn't deal with string input/output (although that'd make DateTime a lot less useful, I think). As things stand, the lack of a parse() method represents a gap in functionality, IMO. -John
Re: DateTime parse(), parser()
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; as well. The latter use would then take an array of additional Format modules to use when parsing (if desired). Why not have them at all? Okay, so defer parser class loading until the last minute. Then all you have is a dozen or so more lines of code in DateTime. Is that going to kill you? :) No, but it might kill me ;) I'm getting concerned about DateTime bloating, not so much in terms of code, but in terms of features. Every feature requires more docs, and more docs means that it becomes harder and harder to figure out how to do the one thing _you_ want DT.pm to do. I think this is a very important feature. If DateTime didn't have strftime() already, then maybe I'd buy the argument that DateTime is just an object representation of dates and doesn't deal with string input/output (although that'd make DateTime a lot less useful, I think). As things stand, the lack of a parse() method represents a gap in functionality, IMO. Yeah, maybe ... -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: integrate leap seconds with core XS code?
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 using pure Perl. But when you upgraded DT::LeapSecond it would not recompile DateTime. That's bad. Yeah, that would be bad. The main reason I hadn't integrated this earlier was that for some reason, I thought leap seconds were announced with very little warning (1-2 days), but I found out that they're actually announced 6 months ahead. Six months is plenty of time to release a new DateTime.pm package, so I don't see any reason not to integrate it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime parse(), parser()
On 7/14/03 3:36 PM, Dave Rolsky wrote: I'm getting concerned about DateTime bloating, not so much in terms of code, but in terms of features. Every feature requires more docs, and more docs means that it becomes harder and harder to figure out how to do the one thing _you_ want DT.pm to do. DT is only as complex as it needs to be, IMO :) And a good examples or tutorial section in the docs will go a long way towards letting users quickly and easily figure out how to do most common tasks. Of course, one of those common tasks is probably going to be parsing simple date formats. As a user, would you rather be told, Go explore the various the DT::F::* modules until you find what you need. Then download and install that module, load it, and use it to parse your dates. Then come back to these docs to learn more about those date objectsor...You can probably just use parse() if your date formats are simple. Here's an example, and here's a link to the parse() entry in this document. If your dates are more complex, then see the DT::F::* modules and the parser() method. I think this is a very important feature. If DateTime didn't have strftime() already, then maybe I'd buy the argument that DateTime is just an object representation of dates and doesn't deal with string input/output (although that'd make DateTime a lot less useful, I think). As things stand, the lack of a parse() method represents a gap in functionality, IMO. Yeah, maybe ... Search your feelings, you know it to be true! :) -John
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
Re: DateTime parse(), parser()
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 time zone to pick the default, or is that too clever by half? :) I'd probably vote for DateTime::Format::HTTP as it copes with a lot of the common formats. Poaching from Date::Parse, as suggested by Dave (I think), is my favorite idea for DT::F::Simple's scope so far. -John
DT::F::DBI docs
There was a recent thread out on perlmonks regarding the functionality of DT::F::DBI: http://www.perlmonks.org/index.pl?node_id=274054 Basically the user did not realize they were dealing with a factory and that the API was actually documented, in their case, in DT::F::MySQL. Perhaps a note in the docs saying for more information see the documentation for the class pertaining to your particular dbh... Or is this supposed to be polymorphic behavior, with all the db format classes sharing the same API...in which case the API should then appear in the main docs? Cheers, Matt
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On 7/14/03 11:10 PM, Ben Bennett wrote:
I am taking a whack at DT::F::Simple (please speak up now if anyone
else wants to claim this project) that can parse things that are
similar to the ones that Date::Parse can do.
Sweet, someone took the bai--...er, picked up the baton ;)
Namely:
- Rough ISO8601 strings (only complete datetimes and dates)
- Dates with '-', '.', or '/' separators (either by month number or
localized short or long name)
- Times with ':' or '-' separator and optional localized AM/PM
- Day names will be used to sanity check the parsed date if present
- I will use localized BC/AD if present
I'm sure you're already doing this, but just in case, make sure to allow for
single-digit numbers where there is no ambiguity. This is essential for
handling user-created input. Examples:
9/3/2002 (e.g. don't require 09/03/2002)
1:02 (e.g. don't require 01:02)
and maybe even:
200210131:02
but that may make some people break out in hives, so whatever :) Also,
don't forget about the optional . in a.m. and p.m. I'm not quite sure
how that'd get localized, but the point is that the localized am/pm thingies
must be regexes, not constant strings (or, okay, a regex constructed out of
a list of constant strings, if you want :)
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.
Don't. Make it a setting. I've been trying to think of what to name this
setting, but have no good ideas. Here are some bad ones instead:
DT::F::Simple-use_mmdd(1);
DT::F::Simple-use_ddmm(1);
DT::F::Simple-mode('us');
DT::F::Simple-mode('euro');
DT::F::Simple-euro_mode(1);
DT::F::Simple-us_mode(1);
Gah, that's horrible :) Someone out there must have some sort of
pre-existing vocabulary to describe the date format differences. Is it just
regional, or are there ISO numbers to reference or what?
-John
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
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 I am not the only person who will want to know that. So could we break it out as an explicit method? We'd have to look at the _actual_ format strings to do this, but it's certainly possible. Also the start of week infomation (and the weekend start and end) seem pretty useful for the financial stuff. Would it be reasonable to add them to the Locale objects? Probably. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
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, since it's supposed to handle common formats (for some value of common). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
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 common formats (for some value of common). How about DateTime::Format::Common::Basic::Simple? -J --
