Re: DateTime parse(), parser()
Rick Measham <[EMAIL PROTECTED]> schrieb/wrote: > DateTime::Undef :) > If all modules return DateTime::Undef and all modules handle it when > passed it, then everything flows. > If we return undef, then we need to make sure all methods can handle > undef parameters cleanly. Of course, we really can't do this because: > undef->set( day=>$day ) > is an error .. no matter what! Actually, DT::Undef is just a special case of the proposed DT::Partial object. If you call set on such an object, it should probably re-bless the reference to DT::Partial and return a DT::Partial object in which only the set field is valid. Claus -- http://www.faerber.muc.de
Re: DateTime parse(), parser()
John Siracusa <[EMAIL PROTECTED]> schrieb/wrote: > 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 don't like the idea that a programme mysteriously works on one machine and fails on another. Different behaviour should be explicitly activated by the user (i.e. the programmer who write a script using the module). Claus -- http://www.faerber.muc.de
Re: DateTime parse(), parser()
Dave Rolsky <[EMAIL PROTECTED]> schrieb/wrote: > Fatal errors are a _good_ thing. Forging ahead with bad data and _not_ > getting errors is a very, very, very bad thing. DBI has an option RaiseError. We could: . have a variable $DateTime::AutoRaise (which should be overridden using local) . have a class factory (in DT::Format) that does the correct thing given input from parsers, i.e.: . returns a DateTime object if everything is correct. . returns a DateTime::Partial object if some data is missing. . returns a DateTime::Undef or throws an exception if there's incorrect data, depending on the setting of $DateTime::AutoRaise. Parsers should only parse; all of the above is common code that should not be re-implemented in all parsers. Claus -- http://www.faerber.muc.de
Re: DT::F::DBI docs
> 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??? Plus several more I didn't list. Anyone feel like volunteering? -J --
Re: DateTime parse(), parser()
> 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 --
Re: Changable locale data...
Speed? -ben On Tue, Jul 15, 2003 at 09:42:02PM -1000, Joshua Hoblitt wrote: > On Tue, 15 Jul 2003, Dave Rolsky wrote: > > > On Tue, 15 Jul 2003, Ben Bennett wrote: > > > > > DateTime::Locale objects return references to internal data. So if a > > > caller changes things through the ref subsequent calls will see the > > > bogus data. > > > > > > I am not sure if this is a problem or not, but we should at least > > > document that the caller _must_not_ change things through the ref. > > > > The locale objects really aren't intended to be used by end-users. But > > yes, this should probably be documented. > > Is there a good reason to return a direct reference? > > -J > > --
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Wed, Jul 16, 2003 at 12:05:00PM +0200, Claus Färber wrote: > Iain Truskett <[EMAIL PROTECTED]> schrieb/wrote: > > * Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]: > > 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. > > Maybe DateTime::Format::Universal? Urm... I am a little reluctant to claim that I parse the universe of dates... > Not all languages use suffixes when writing numbers. In German, for > example, you'd just write "14. Juli". (Actually, it's spoken > "vierzehn*ter* Juli", but one does not write "14ter Juli"; in spoken > language, the suffix is also used for the month as in "vierzehnter > siebter" or "14ter 7ter"). Great! Someone who can tell me real German usage! In the example above, is the . after 14 optional? I assume so... Can you clarify what AM/PM and BC/AD forms would be expected? Thank you! -ben
Re: DateTime parse(), parser()
Rick Measham <[EMAIL PROTECTED]> schrieb/wrote: >> Right, they won't bother using the eval (at first) and so will be forced >> to deal with data problems. Why is that bad? > Same with not using $dt->is_undef. At least the programme fails and prints an error message instead of silently using wrong data. Claus -- http://www.faerber.muc.de
Re: Ambiguous years (what does 03 mean?)
Rick Measham <[EMAIL PROTECTED]> schrieb/wrote: > It's in the year 3 A.D. Period. This is a 'simple' module so I don't > think it should try bending user input too much. If you assume it to be > 2003, then how do I say it's the year 3? 02/11/0003 Claus -- http://www.faerber.muc.de
Re: DateTime::Format::Pg problem
Alex Boster <[EMAIL PROTECTED]> schrieb/wrote: > DateTime::Format::Pg dies when I parse an ISO date. Can anyone point me > in the right direction? I looked at the module's code, and I can't find > the problem. The regex should match and fractional_seconds is in fact > on the params list. As Ben already pointed out, the new version of DateTime does not allow fractional_seconds. I've just updated DateTime::Format::Pg to work with DateTime 0.13 (it may take some hours until it becomes available through CPAN, though). Claus -- http://www.faerber.muc.de
Re: DateTime parse(), parser()
Here's my take on handling parse errors, and error handling in general.
1. I don't like to (unconditionally) die from within libraries except for
conditions that are totally avoidable. For example, I die if you forget to
send a required argument. But I would not die in a parse() function that is
expected to handle user-created input! That would force everyone to use an
exception-handling style of error checking just to use your modules, which
is not nice.
2. I use plain old undef as my error return value, but I sometimes document
the methods saying that any false value is an indication that there was an
error. This works in all methods that return objects (which is most of the
ones I write, and any parsing method in DT).
3. I make sure I store some sort of sensible error message or code somewhere
convenient, letting the user of the library know why something failed. Even
if it's only "Invalid date: 'foobar'", it goes a long way towards making
debugging easier.
I think this system gives the most flexibility to the user of a library.
Examples:
# Use fatal errors
$dt = DateTime->parse(...) or die DateTime->error;
$dt->parse(...) or die $dt->error;
# Use non-fatal errors
if($dt = DateTime->parse(...)) { ... }
else { warn DateTime->error }
if($dt->parse(...)) { ... }
else { warn $dt->error }
# Use exception handling
eval
{
$dt = DateTime->parse(...) or die DateTime->error;
$dt->parse(...) or die $dt->error;
...
};
if(@$) { ... }
Finally, I want to immediately help anyone who does this:
$dt = DateTime->parse(...);
$dt->set(...);
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:
$dt = DateTime->parse(...) || DateTime::Undef->new;
which is a lot clearer, IMO. Also, I don't think DT::Infinite is in the
same boat, because that is a legitimate date (that DT::F::Simple must parse,
BTW: /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error!
-John
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
Ben Bennett <[EMAIL PROTECTED]> schrieb/wrote: > On Wed, Jul 16, 2003 at 12:05:00PM +0200, Claus Färber wrote: >> Not all languages use suffixes when writing numbers. In German, for >> example, you'd just write "14. Juli". (Actually, it's spoken >> "vierzehn*ter* Juli", but one does not write "14ter Juli"; in spoken >> language, the suffix is also used for the month as in "vierzehnter >> siebter" or "14ter 7ter"). > Great! Someone who can tell me real German usage! In the example > above, is the . after 14 optional? I assume so... Actually, the dot (.) has a function similar to the suffix in other languages (e.g. -st, -nd, -th in English), i.e. it indicates an ordinal number. It is not optional in standard German orthography (that does not mean that everyone always adheres to this rule, of course). > Can you clarify what AM/PM and BC/AD forms would be expected? AM/PM is not used in German-speaking countries. We simply use the 24 hour system when writing down times. (Spoken language is different and often ambiguous but I don't think that's relevant for a parser class.) BC is 'vor Christus' or 'v. Chr.'. AD is 'nach Christus' or 'n. Chr.' Sometimes 'AD' is used, too (very rare; usually only ecclesiastic texts). I'd suggest /v(?:or|\.)?\s*Chr(?:ist(?:us)|\.)?/ and /n(?:ach|\.)?\s*Chr(?:ist(?:us)|\.)?/ as patters to conver most non- standard variants. Claus -- http://www.faerber.muc.de
RE: nmake test failure on perl 5.8.0 CVS version of datetime.pm
Hi Dave, [snipped] > > > The test was wrong, I believe. Either that or the locale had > a bug that is now fixed. yes, It now passes on 5.8.0 [more snippage] > I can't stress this enough. When tests fail, please rerun > the tests with 'make test TEST_VERBOSE=1 TEST_FILES=t/...' > This gives me extra info that makes it easier to track down > the failures. OK, I'm sorry about that. I will include this in the future G:\modules\DateTime.pm>nmake test TEST_VERBOSE=1 TEST_FILES=t/20infinite.t Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. F:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(1, 'blib\lib', 'blib\arch )" t/20infinite.t t/20infinite1..37 ok 1 - positive infinity should be infinite ok 2 - negative infinity should be infinite ok 3 - positive infinity should not be finite ok 4 - negative infinity should not be finite ok 5 - negative infinity is really negative ok 6 - positive infinity is really positive ok 7 - positive infinity is bigger than negative infinity ok 8 - infinity - normal = infinity ok 9 - normal + infinite duration = infinity ok 10 - normal - infinity = neg infinity not ok 11 - normal + neg infinite duration = neg infinity # Failed test (t/20infinite.t at line 53) # got: 'DateTime::Infinite::Future=HASH(0x1e2f4a0)' # expected: 'DateTime::Infinite::Past=HASH(0x1dfee58)' not ok 12 - infinity - infinity = nan (days) # Failed test (t/20infinite.t at line 61) # got: '-2147483648' # expected: '2147483648' not ok 13 - infinity - infinity = nan (seconds) # Failed test (t/20infinite.t at line 61) # got: '-2147483646' # expected: '2147483648' ok 14 - infinity + normal duration = infinity ok 15 - infinity - normal duration = infinity ok 16 - infinity (datetime) == infinity (number) ok 17 - neg infinity (datetime) == neg infinity (number) ok 18 - pos year is 1.\#INF ok 19 - neg year is 1.\#INF ok 20 - pos month is 1.\#INF ok 21 - neg month is 1.\#INF ok 22 - pos day is 1.\#INF ok 23 - neg day is 1.\#INF ok 24 - pos hour is 1.\#INF ok 25 - neg hour is 1.\#INF ok 26 - pos minute is 1.\#INF ok 27 - neg minute is 1.\#INF ok 28 - pos second is 1.\#INF ok 29 - neg second is 1.\#INF ok 30 - pos microsecond is 1.\#INF ok 31 - neg microsecond is 1.\#INF ok 32 - pos millisecond is 1.\#INF ok 33 - neg millisecond is 1.\#INF ok 34 - pos nanosecond is 1.\#INF ok 35 - neg nanosecond is 1.\#INF ok 36 - positive infinite is greater than now ok 37 - negative infinite is less than now # Looks like you failed 3 tests of 37. dubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 11-13 Failed 3/37 tests, 91.89% okay Failed TestStat Wstat Total Fail Failed List of Failed --- t/20infinite.t3 768373 8.11% 11-13 Failed 1/1 test scripts, 0.00% okay. 3/37 subtests failed, 91.89% okay. NMAKE : fatal error U1077: 'F:\perl\bin\perl.exe' : return code '0x2' Stop. G:\modules\DateTime.pm> > > I have no idea why this would suddenly start failing when it > seemed to be fine last go-round. yes, I checked this test using 5.6.1 and these tests pass on W2K > I hate infinite numbers. I hate Windows. > Whoever suggested DT::Infinite, damn you! > [more snippage] > > Just 5.8.0? Oh, goody. nope :( I tried this with perl 5.8.1 RC2 and receive the same types of errors. > > Absent someone with understanding IEEE math and how it works > on Win32, I consider this unlikely to get fixed. > I sure as heck don't know what's going on. neither do I. Hopefully, someone on the DateTime list can step up and take a look at it. > I may simply add something to the DT::Infinite > docs saying that it's known to be broken on Win32. > I hope this helps. Ron Hill
Re: DateTime parse(), parser()
On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote: [snip] > IMO. Also, I don't think DT::Infinite is in the same boat, because > that is a legitimate date (that DT::F::Simple must parse, BTW: > /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error! Is infinity really a simple date? I think no. Anyone else want to weigh in? -ben
Re: DateTime parse(), parser()
On 7/16/03 11:21 AM, Ben Bennett wrote:
> On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
> [snip]
>> IMO. Also, I don't think DT::Infinite is in the same boat, because
>> that is a legitimate date (that DT::F::Simple must parse, BTW:
>> /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error!
>
> Is infinity really a simple date? I think no. Anyone else want to
> weigh in?
Either way, I'll weigh in again! :) Of course it's "simple" because, in the
context of DT::F::Simple, "simple" means "simple to parse." And this is
pretty darned simple, IMO:
if(/^([-+])?inf(?:inity)?$/i)
{
if($1 eq '-')
{
return DateTime::Infinite::Past->new;
}
return DateTime::Infinite::Future->new;
}
-John
Re: DateTime parse(), parser()
On Wed, 16 Jul 2003, John Siracusa wrote:
> Here's my take on handling parse errors, and error handling in general.
>
> 1. I don't like to (unconditionally) die from within libraries except for
> conditions that are totally avoidable. For example, I die if you forget to
> send a required argument. But I would not die in a parse() function that is
> expected to handle user-created input! That would force everyone to use an
> exception-handling style of error checking just to use your modules, which
> is not nice.
Yeah, I can buy this, since parsing is inherently something that can fail,
and it often need not be fatal, because it doesn't indicate a usage error,
as opposed to bad parameters.
> 2. I use plain old undef as my error return value, but I sometimes document
> the methods saying that any false value is an indication that there was an
> error. This works in all methods that return objects (which is most of the
> ones I write, and any parsing method in DT).
This also makes sense.
> 3. I make sure I store some sort of sensible error message or code somewhere
> convenient, letting the user of the library know why something failed. Even
> if it's only "Invalid date: 'foobar'", it goes a long way towards making
> debugging easier.
>
> I think this system gives the most flexibility to the user of a library.
> Examples:
>
> # Use fatal errors
> $dt = DateTime->parse(...) or die DateTime->error;
> $dt->parse(...) or die $dt->error;
>
> # Use non-fatal errors
> if($dt = DateTime->parse(...)) { ... }
> else { warn DateTime->error }
>
> if($dt->parse(...)) { ... }
> else { warn $dt->error }
>
> # Use exception handling
> eval
> {
> $dt = DateTime->parse(...) or die DateTime->error;
> $dt->parse(...) or die $dt->error;
> ...
> };
>
> if(@$) { ... }
>
> Finally, I want to immediately help anyone who does this:
>
> $dt = DateTime->parse(...);
> $dt->set(...);
>
> 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:
>
> $dt = DateTime->parse(...) || DateTime::Undef->new;
I agree.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime parse(), parser()
On Tue, 15 Jul 2003, Joshua Hoblitt wrote: > > > 2. My option: > > > $day_of_month = ; > > > $dt->set( day => $day_of_month )->truncate( to => 'day' ); > > > print "Your day must be a number in the current month" if > > > $dt->is_undef; > > > > See, most people won't _bother_ with the 3rd line in option 2! They'll > > just go ahead and use the data. > > How many check to see if it is DT::Infinite? None of the parsing modules currently return that, and I'm not sure that they should. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime parse(), parser()
On Tue, 15 Jul 2003, Joshua Hoblitt wrote: > We were talking about returning DT::Undef objects from parsers. So, for > example, if the _format_ being parsed _defines_ an unknown or undefined > date/time an object can be returned that reflects this. Simply > returning undef when an object is expected is, IMHO, not a correct > behavior. Sure, if the format has something for unknown, I can see the usefulness of such an object, although since undef also indicates unknown, I'm not sure that's so bad. > My fear is that people will start returning DT objects set to something > like -01-01T00:00:00 to indicate this case. Yeah, that'd be ugly. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::F::DBI docs
On Wed, 16 Jul 2003, Joshua Hoblitt wrote: > Pheonix 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 ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::F::DBI docs
Joshua Hoblitt schreef: > > Well, there are only two modules: DT::F::MySQL and DT::F::Pg. > > I'd really like to see a lot more database formatters. 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. Should there be a default format DT::F::SQL for DT::F::DBI? (I don't know if SQL defines a date format, so I don't know if this is possible.) Eugene P.S. Anyone interested in DateTime::Format::CSV?
Re: DateTime parse(), parser()
Well, I don't think that the simple is supposed to indicate simple to
parse (at the moment the parser is all but simple... but I am trying
to clean it up). I read it as "simple formats", i.e. common formats
that define the date and time in fairly straightforward ways (month names
and numbers for things are fine, "next week" "third thursday in the
next month with a blue moon" are not).
The other problem I see is that your regexp only covers English
speaking locales... I am currently using the DateTime::Locale date to
get locale sensitive information for parsing month and day names.
(Although AM/PM and BC/AD are a bit of a problem, I may need to add
extra information somewhere).
-ben
On Wed, Jul 16, 2003 at 11:30:33AM -0400, John Siracusa wrote:
> On 7/16/03 11:21 AM, Ben Bennett wrote:
> > On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
> > [snip]
> >> IMO. Also, I don't think DT::Infinite is in the same boat, because
> >> that is a legitimate date (that DT::F::Simple must parse, BTW:
> >> /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error!
> >
> > Is infinity really a simple date? I think no. Anyone else want to
> > weigh in?
>
> Either way, I'll weigh in again! :) Of course it's "simple" because, in the
> context of DT::F::Simple, "simple" means "simple to parse." And this is
> pretty darned simple, IMO:
>
> if(/^([-+])?inf(?:inity)?$/i)
> {
> if($1 eq '-')
> {
> return DateTime::Infinite::Past->new;
> }
>
> return DateTime::Infinite::Future->new;
> }
>
> -John
Re: DateTime parse(), parser()
On Tuesday, July 15, 2003, at 11:11 PM, Rick Measham wrote: I'm an anti-fan of die. Die requires wrapping in eval or parsing the user's input before passing to ->parse_datetime, which is just crazy. We should only throw errors on programmer error. For example: $dt->set( weekday => 'Friday' ); should error because there's no 'weekday' parameter for set(). However, we should return DateTime::Undef on user error: $dt->set( day => 'Twenty-two' ); because it means that we can now test for DateTime::Undef, letting set() do the parsing of the user's input. This is why you use exception objects, and throw different exceptions for user errors vs. programmer error. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Ambiguous years (what does 03 mean?)
Claus F?rber schreef: > Rick Measham <[EMAIL PROTECTED]> schrieb/wrote: > > It's in the year 3 A.D. Period. This is a 'simple' module so I don't > > think it should try bending user input too much. If you assume it to be > > 2003, then how do I say it's the year 3? > > 02/11/0003 Nope. With that input, it's very likely that the user has made a typo. It should be auto-corrected to 2003, of course. Eugene
Re: DateTime parse(), parser()
On 7/16/03 1:40 PM, Ben Bennett wrote: > Well, I don't think that the simple is supposed to indicate simple to > parse (at the moment the parser is all but simple... but I am trying > to clean it up). I read it as "simple formats", i.e. common formats > that define the date and time in fairly straightforward ways (month names > and numbers for things are fine, "next week" "third thursday in the > next month with a blue moon" are not). What is the advantage of excluding things that are simple to parse, but not "conceptually simply"? I'd actually argue that infinity is pretty "straightforward" anyway, and important enough to have its own DT classes already. The default "simple" parser should be able to return infinite dates under some "simple" circumstances. Parsing "+/-infinity" is such a circumstance, IMO. > The other problem I see is that your regexp only covers English > speaking locales... I am currently using the DateTime::Locale date to > get locale sensitive information for parsing month and day names. > (Although AM/PM and BC/AD are a bit of a problem, I may need to add > extra information somewhere). I don't think infinity needs to be locale aware. "Inf" will not be locale aware in Perl 6, AFAIK, for example. "+/-infinity" should be parsed as a constant representing the mathematical construct, not as an attempt to catch user input like "forever and ever." -John
Re: DateTime parse(), parser()
John Siracusa schreef: > On 7/16/03 1:40 PM, Ben Bennett wrote: > > What is the advantage of excluding things that are simple to parse, but not > "conceptually simply"? Not confusing the user who doesn't need it. If you want anything complex, either to parse or to conceptualisate, then you're supposed to be able to select the correct Format module to use. > I'd actually argue that infinity is pretty "straightforward" anyway, and > important enough to have its own DT classes already. I don't want the default parser (if such a thing, godforbid, is implemented) to be able to return DT::Inf! Take the following example: $dt = DateTime->parse( $user_input ) or die "invalid date $user_input"; print CONFIGFILE DateTime::Format::MyConfig->format_datetime($dt); This should just work. Most of the formatting modules don't know what to do with infinite dates. Similarly, most of the programs using DT won't use infinite dates. It is a pain to check for infinity everywhere. In a DT::F::NotSoSimple, that is not the default, there is no problem with returning an infinite datetime. Those modules have to be selected by the programmer anyway, so as long as it is documented that it can return DT::Inf, the programmer gets what he asks for. > I don't think infinity needs to be locale aware. "Inf" will not be locale > aware in Perl 6, AFAIK, for example. Perl 6 is for programmers. I thought you needed the DT::F::Simple module for user input. If English users try to submit the string "infinite" in a web form (I doubt it, but hypothetically...), Dutch users would certainly type "oneindig". Eugene
Re: DateTime parse(), parser()
On 7/16/03 2:16 PM, Eugene van der Pijll wrote: > Most of the formatting modules don't know what to do with infinite dates. That's a bug/feature in the formatting modules, IMO, not a reason to pretend that infinite dates don't exist. > Similarly, most of the programs using DT won't use infinite dates. It is a > pain to check for infinity everywhere. ...and yet you must do so anyway if you write subroutines that accept DateTime objects, but that want to reject infinite dates. >> I don't think infinity needs to be locale aware. "Inf" will not be locale >> aware in Perl 6, AFAIK, for example. > > Perl 6 is for programmers. I thought you needed the DT::F::Simple module > for user input. Programmers are users too :) In this situation, you can think of it as a shorter constructor for brief/simple scripts (since the arguments to DateTime->new() are very verbose). This was another one of the motivators for DT::F::Simple, if you look back at the thread. > If English users try to submit the string "infinite" in a web form (I doubt > it, but hypothetically...), Dutch users would certainly type "oneindig". I'm not really "against" localization in this case. I think "natural language" is outside the scope of DT::F::Simple. Simple things like "now" and "today" should get parsed, but not "right now" or "the day after yesterday" :) I'm just not sure how cleanly "infinity" will localize. And since it is a mathematical concept as well as a regular word (and probably used in the former context more often), I don't think it would be the end of the world if it wasn't localized. That's all I'm saying. -John
Re: DateTime parse(), parser()
John Siracusa schreef: > On 7/16/03 2:16 PM, Eugene van der Pijll wrote: > > Most of the formatting modules don't know what to do with infinite dates. > > That's a bug/feature in the formatting modules, IMO, not a reason to pretend > that infinite dates don't exist. Infinite dates do not exist. (And neither do undefined ones.) > > Similarly, most of the programs using DT won't use infinite dates. It is a > > pain to check for infinity everywhere. > > and yet you must do so anyway if you write subroutines that accept > DateTime objects, but that want to reject infinite dates. A Format object does not have to accept every deranged monstrosity that is subclassed from DateTime. For example, my Format modules are documented to accept DateTime objects. > >> I don't think infinity needs to be locale aware. "Inf" will not be locale > >> aware in Perl 6, AFAIK, for example. > > > > Perl 6 is for programmers. I thought you needed the DT::F::Simple module > > for user input. > > Programmers are users too :) In this situation, you can think of it as a > shorter constructor for brief/simple scripts (since the arguments to > DateTime->new() are very verbose). This was another one of the motivators > for DT::F::Simple, if you look back at the thread. I know, and it would be mine. But this means that DT::F::Simple would try to be two things: 1) it wants to parse all common datetime strings that a (naive?) user would pass to the program. To do this, it has to be as lenient as possible, whilst being aware of locale issues, and if possible, it should be able to interpret the most likely meaning of defective input like 01/02/03. It should be able to parse such simple phrases as 'now', but not unintuitive mathematical concepts. 2) it wants to provide a shorter constructor. To do this, it should be exactly defined how formats are interpreted. Special phrases are provided to construct some special DT constructs (aka deranged monstrosities), like '+inf' and '-inf'. It is not necessary to duplicate other methods, so e.g. 'now' is not needed; DateTime::now() is perfectly adequate. Combining these two aims is perhaps possible. Calling the result Simple is a chutzpah. Making it the default for DT parsing... > > If English users try to submit the string "infinite" in a web form (I doubt > > it, but hypothetically...), Dutch users would certainly type "oneindig". > > I'm not really "against" localization in this case. I think "natural > language" is outside the scope of DT::F::Simple. But "natural date formats" are inside the scope of DT::F::S, right? And "infinite" is a date, right? > Simple things like "now" > and "today" should get parsed, but not "right now" or "the day after > yesterday" If "today" is parsed, people expect "tomorrow" to be parsed as well". And if "tomorrow" is parsed, "overmorrow" should also be parsed. (At least, in those languages where the word "overmorrow" is not deprecated.) (Rick! Does DT::F::Natural parse "overmorrow" already? "ere-yesterday"?) Eugene
Re: DateTime parse(), parser()
> 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. > which is a lot clearer, IMO. Also, I don't think DT::Infinite is in the > same boat, because that is a legitimate date (that DT::F::Simple must parse, > BTW: /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error! Null is a just as legitimate as Inf. The idea here is to "encode knowledge". The lack of a date/time is valid information. -J --
Re: DT::F::DBI docs
> 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 --
Re: DT::F::DBI docs
> 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 might get a bit confusion for end users. -J --
Re: DateTime parse(), parser()
> 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 --
Re: DT::F::DBI docs
On Wed, 16 Jul 2003, Joshua Hoblitt wrote: > > 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 might get a bit confusion for end > users. Plus X may change in the future. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT constructor
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 this? It should work for both
subclasses and decorators. If these changes were repeated to the other constructors I
could write DT::Wrap::Validator as a decorator class.
-J
--
Index: lib/DateTime.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
retrieving revision 1.217
diff -u -r1.217 DateTime.pm
--- lib/DateTime.pm 15 Jul 2003 18:58:08 - 1.217
+++ lib/DateTime.pm 16 Jul 2003 08:18:45 -
@@ -155,7 +155,7 @@
sub new
{
my $class = shift;
-my %p = validate( @_, $NewValidate );
+my %p = __PACKAGE__->_preprocess_new_params( @_ );
my $last_day = $class->_last_day_of_month( $p{year}, $p{month} );
@@ -218,6 +218,14 @@
}
return $self;
+}
+
+sub _preprocess_new_params
+{
+ my $self = shift;
+ my @p = validate( @_, $NewValidate );
+
+ return @p;
}
sub _calc_utc_rd
Re: DateTime parse(), parser()
On 7/16/03 3:39 PM, Eugene van der Pijll wrote: > John Siracusa schreef: >> On 7/16/03 2:16 PM, Eugene van der Pijll wrote: >>> Most of the formatting modules don't know what to do with infinite dates. >> >> That's a bug/feature in the formatting modules, IMO, not a reason to pretend >> that infinite dates don't exist. > > Infinite dates do not exist. Infinite DateTime objects do, which was my point. > A Format object does not have to accept every deranged monstrosity that > is subclassed from DateTime. For example, my Format modules are > documented to accept DateTime objects. DateTime::Infinite is a "deranged monstrosity" now!? Yeesh :) Regardless of your opinion of it, DateTime::Infinite is very useful to many people. > this means that DT::F::Simple would try to be two things: > > 1) it wants to parse all common datetime strings that a (naive?) user > would pass to the program. To do this, it has to be as lenient as > possible, whilst being aware of locale issues, and if possible, it > should be able to interpret the most likely meaning of defective input > like 01/02/03. It should be able to parse such simple phrases as 'now', > but not unintuitive mathematical concepts. > > 2) it wants to provide a shorter constructor. To do this, it should be > exactly defined how formats are interpreted. Special phrases are > provided to construct some special DT constructs (aka deranged > monstrosities), like '+inf' and '-inf'. It is not necessary to duplicate > other methods, so e.g. 'now' is not needed; DateTime::now() is perfectly > adequate. > > Combining these two aims is perhaps possible. I never suggested that ambiguous forms should be parsed by DT::F::Simple. The two-digit years thread was started by someone else :) I think it should parse common, unambiguous, easy to parse date strings. > Calling the result Simple is a chutzpah. Like I said earlier, maybe ::Basic is better. But ::Simple is how we've been discussing it so far, so I'm trying to avoid confusion :) > Making it the default for DT parsing... ...is the key feature of the whole system! (That's what you were going to say, right? ;) > If "today" is parsed, people expect "tomorrow" to be parsed as well" Well, you could just set a policy to avoid anything that requires date math. But if you do want to accept "tomorrow", DT makes it pretty easy with $dt->add(days => 1), unless I'm missing something... :) -John
Re: DT::F::DBI docs
Joshua Hoblitt schreef: > > 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 might get a bit confusion for end > users. Hmmm. I count 47 different DBD modules. That means 47 DT::F modules? (You're right about the confusion. Unless we could train end users to trust DT::F::DBI. The Perlmonks discussion that prompted this thread started when an end user made the 'mistake' to look only at DT::F::DBI, and not at the MySQL module, so it _is_ possible...) Eugene
Re: DateTime parse(), parser()
Joshua Hoblitt schreef: > > 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. Sure. If the programmer chooses to, by choosing modules that return them. 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. Specifically, the default parser should not return these things, and other parsers (the DBI ones, for example) should document that they can return DT::Undef or DT::Inf. IMHO, as always. Eugene
Re: DateTime parse(), parser()
On Wed, 16 Jul 2003, Eugene van der Pijll wrote: > 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. > > Specifically, the default parser should not return these things, and > other parsers (the DBI ones, for example) should document that they can > return DT::Undef or DT::Inf. I'm inclined to agree with you here. End users should not be getting back DT::Inf or DT::Undef (if the latter eventually exists) unless they explicitly declare that they are working in a domain where such things exist. This can be done by using a specific formatting module, for example for a database which can store infinite datetime values. Or by using the set math code, which definitely opens up the possibility of infinity. But otherwise, I'd prefer that the user not even have to know that DT::Infinite exists, because for _many_ people, they won't understand what it is for. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime parse(), parser()
John Siracusa schreef: > On 7/16/03 3:39 PM, Eugene van der Pijll wrote: > > Infinite dates do not exist. > > Infinite DateTime objects do, which was my point. The Loch Ness monster exists. That doesn't mean that DateTime::Format::Roman should accept it. > > A Format object does not have to accept every deranged monstrosity that > > is subclassed from DateTime. For example, my Format modules are > > documented to accept DateTime objects. > > DateTime::Infinite is a "deranged monstrosity" now!? Yeesh :) Regardless > of your opinion of it, DateTime::Infinite is very useful to many people. I must admit that at this point my analogy with the Loch Ness monster may be said to break down. > I never suggested that ambiguous forms should be parsed by DT::F::Simple. Not even 04/05/2003? > > If "today" is parsed, people expect "tomorrow" to be parsed as well" > > Well, you could just set a policy to avoid anything that requires date math. Is DT::truncate date math? If so, this disqualifies "today"... Oh, I forgot one: if "now" is parsed, "never" should be as well (returning DT::Undef). (That one is somewhat sensible to include, even.) Eugene
Re: DateTime parse(), parser()
On 7/16/03 4:17 PM, Eugene van der Pijll wrote:
>> I never suggested that ambiguous forms should be parsed by DT::F::Simple.
>
> Not even 04/05/2003?
That's not ambiguous, thanks to the handy setting in DT::F::Simple that
tells it exactly how to interpret that :)
>>> If "today" is parsed, people expect "tomorrow" to be parsed as well"
>>
>> Well, you could just set a policy to avoid anything that requires date math.
>
> Is DT::truncate date math? If so, this disqualifies "today"...
You don't necessarily need to use truncate to handle "today" (e.g. It could
just be documented to mean 00:00:00), but no, I wouldn't consider truncation
to be "date math."
> Oh, I forgot one: if "now" is parsed, "never" should be as well
> (returning DT::Undef). (That one is somewhat sensible to include, even.)
...unless you consider all such things to be "deranged monstrosities"! :)
On 7/16/03 4:16 PM, Dave Rolsky wrote:
> End users should not be getting back DT::Inf or DT::Undef (if the latter
> eventually exists) unless they explicitly declare that they are working
> in a domain where such things exist.
Like I said earlier, if your code accepts DateTime objects, but doesn't want
to deal with infinite dates, then you've got to explicitly check for
finite-ness anyway. I don't think you can just *assume*, based on a choice
(default or otherwise) of DT::F:: modules, whether or not infinite dates
will ever cross their (code) path.
If you want to put the onus on the user to read the particular DT::F::
module's documentation to see what kinds of DateTime objects could possibly
be returned, then users will have to do the same for DT::F::Simple. And in
that case, DT::F::Simple just has to document what it can return.
Finally, if you're just trying to go for the "principle of least surprise",
then I don't think a programmer would be surprised that
DateTime->parse('infinity');
returns an infinite date! It's not like infinite dates are going to just
start spewing fourth from DateTime->parse() randomly :)
-John
Re: DateTime parse(), parser()
> 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 that needs to be filled for completeness. > Specifically, the default parser should not return these things, and > other parsers (the DBI ones, for example) should document that they can > return DT::Undef or DT::Inf. Sounds reasonable. -J --
Re: DateTime parse(), parser()
Eugene van der Pijll wrote: > Oh, I forgot one: if "now" is parsed, "never" should be as well > (returning DT::Undef). (That one is somewhat sensible to include, even.) "now" is a DT, or a DT function "never" is DT::Set->new_empty "forever" is DT::Set( -inf, inf ) "undef" is DT::Undef - Flavio S. Glock
Re: DateTime parse(), parser()
> 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 --
