Re: RFC: DateTime::Event::DateTime (or something)
On Tue, 15 Jul 2003, Rick Measham wrote: Will this be useful to anyone other than me? Yes, I think it's somewhat useful for end users and definitely useful other module authors. Is there a better name? I sure hope so, because I _really_ don't want to see something called DT::Event::DT on CPAN! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Time::Local 1.07_90
If people on non-Unix platforms could try this out I'd be quite grateful. I'm especially interested in hearing from Win32 and Mac users. Also, if anyone has a platform where time_t is not a 32-bit int, that'd be another interesting place to test. 1.07_90 - Fixed behavior for edge cases like timegm(gmtime(0x7FFF_)), which should work even on platforms where time_t is signed. Patch from Henrik Gulbradsen. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, Jul 15, 2003 at 01:56:53PM +1000, Iain Truskett 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.
Ok. I will think about that (suggestions welcomed).
Sounds good. Ignoring unknown day names?
I think so. I haven't decided yet.
Ommissions from Date::Parse:
- July 14th will not be parsed (I don't have localized info on the
numeric suffixes)
How about you just assume /\d{1,2}\w+/?
Perhaps, I will play with it when the rest is finished. Input from
people who speak other languages would be appreciated. I think that
would be okay in French, I am a bit concerned about how it behaves
with non-Latin languages.
This will use the DT::F::Locales to get the localized forms of the
days and months.
What happens in the event of input being in an unknown locale? As in we
don't know what locale this is in rather than we don't have locale
data for xy_XX.
Erm... maybe later I will make something that can deal with ambiguous
locales. That seems like a non-Simple.pm task (I realize that it
isn't that hard to do, but may be slow).
Not really. The best one can do is have it so dates that can only be one
type and not the other are done correctly. Ambiguity is part of the
reason ISO8601 and W3CDTF have their order specified and why rfc(2)822
uses the month _name_.
If you have the locale then I think you should be able to assume
ordering.
If Simple is to be simple, I'm not sure it can really handle such
things. The idea of Simple modules is to have as little of an
interface as possible. Inner complexity and outer simplicity.
See above.
-ben
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, Jul 15, 2003 at 12:14:00AM -0400, John Siracusa wrote:
On 7/14/03 11:10 PM, Ben Bennett wrote:
[...]
Sweet, someone took the bai--...er, picked up the baton ;)
Well I have been playing around with the idea for a while, but when
the locale stuff got in I decided it was time to stop fiddling and get
something useful together.
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)
Yes.
and maybe even:
200210131:02
No! Egads :-) Actually I wasn't accepting the form 200210130102
either (I will accept 20021013T0102). Should I?
but that may make some people break out in hives, so whatever :)
Scratch, scratch...
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 :)
Yeah, I was trying to work that out. It appears not to be in the raw
locale data, so I was considering just accepting the am/pm stuff with
optional inserted periods, even for other locales. I still have to
survey all locales to see if that is even reasonable. The other
choice would be to special case BC and AD to allow the dotted form,
but that seems a bit restrictive.
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:
It would be a setting... locale.
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?
I can add an optional additional parameter dmy_mode (defaults to your
locale if undef) but I really think inferring it from the locale is
fine.
Speaking of which, what interface do people want?
my $us_parser = DateTime::Format::Simple-new(locale = en_US);
my $dt = $us_parser-parse_datetime(2/11/74);
Or:
my $dt = DateTime::Format::Simple-parse_datetime(string = 2/11/74,
locale = en_US);
Note that it will always be legal to call:
my $dt = DateTime::Format::Simple-parse_datetime(2/11/74);
And some locale will be assumed (probably en_US).
Another choice would be to allow both forms (which I may do to allow
user flexilbility).
-ben
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Mon, Jul 14, 2003 at 11:39:37PM -0500, Dave Rolsky wrote: 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. Ok, I will play around with this and see if all of the locales have understandable short forms. 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. Cool, I may add that in the future if needed. -ben
Re: RFC: DateTime::Event::DateTime (or something)
On Tue, 15 Jul 2003, Rick Measham wrote: Is there a better name? On Tue, 2003-07-15 at 17:41, Dave Rolsky wrote: I sure hope so, because I _really_ don't want to see something called DT::Event::DT on CPAN! That was my thought and the reson I asked the questoin ... seemed a little confusing but at the same time it does suit it. Maybe this is DateTime::Event::Simple? It's simple because the event feels like it requires no complex calculations like Easter or Sunset. (Of course, if you look at the code its not as easy as just callilng Set(), although it feels like it). It's also Simple because the event itself is simply a set of unit values. It's also simple because other modules will (I imagine) use it for calculating events. Maybe it's DateTime::Event::Moment, or DateTime::Event::Custom (nah) or DateTime::Event::FromHash (eww) or DateTime::Event::DateAndTime (hmm) or ... any good ideas anyone? Cheers! Rick
Re: Ambiguous years (what does 03 mean?)
Ben Bennett wrote: Given the date 02/11/03 in the locale en_US (so you can assume m/d/y), what year is that in? As a human I say that is 2003. What should the rule be? Does the following sound reasonable: 1) Work out the current decade (now 00) 2) Any date in the current and next decade (00, 10) are assumed to be in the future 3) All other dates are assumed to be in the past Add the following code (modulo what you called the year variable): if (length($yr) 4) warn (Your year value is indeterminant. Performing SWAG[1]!); Then do a search on Google for y2k window and see how people suggested handling it. Yes, it _is_ completely bogus and arbitrary, why do you ask? But when dealing with malformed data, the old warhorse of GIGO[2] applies. John 1) http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=swagaction=Search 2) http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=gigoaction=Search -- 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::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On 7/15/03 8:05 AM, Ben Bennett wrote: On Tue, Jul 15, 2003 at 12:14:00AM -0400, John Siracusa wrote: 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. [...] Yes. (Also stuff like 10/25/2003 5 p.m. Just checking :) Actually I wasn't accepting the form 200210130102 either (I will accept 20021013T0102). Should I? Yes, definitely for the 200210130102 (or 20021013010259 or 20021013010259.12345) versions. Those aren't ambiguous at all, as far as I can see. I can take or leave the T :) I can add an optional additional parameter dmy_mode (defaults to your locale if undef) but I really think inferring it from the locale is fine. Yeah, that sounds better than trying to come up with names for the setting. Speaking of which, what interface do people want? my $us_parser = DateTime::Format::Simple-new(locale = en_US); my $dt = $us_parser-parse_datetime(2/11/74); Or: my $dt = DateTime::Format::Simple-parse_datetime(string = 2/11/74, locale = en_US); I'd use the first. (Actually, I'd use DateTime-parse(), which would use the first for me :) But I don't see why it can't support both. -John
Re: RFC: DateTime::Event::DateTime (or something)
Try this:
use DateTime::Event::Recurrence;
use DateTime;
$seven = DateTime::Event::Recurrence-daily ( hours = [ 7, 19 ] );
print $seven-next( DateTime-now )-datetime;
- Flavio S. Glock
Rick Measham wrote:
Attached is DateTime::Event::DateTime. No tests, no docs.
This module is a very basic event module. Given parts of a datetime
it can return the following, previous and closest datetime object.
The module was inspired by Ben Bennet who at 8:01 PM -0400 13/7/03, wrote:
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).
So this module does just that. Rather than finding the next 'easter'
or 'sunset', this module finds the next valid datetime matching the
parameters.
$seven_pm = DateTime::Event::DateTime-new(
hour = 19,
truncate = 'hour'
);
$dt = $seven_pm-following( datetime = DateTime-now() )
# Gets the next 7pm after now.
The module can also be used non-OO:
$dt = previous(
datetime = DateTime-now(),
hour = 19
);
# Returns 19:59:59.9, which is the last valid
DateTime with the hour '19'.
Because 'previous' returns results that may be unexpected, the
truncate parameter exists.
Of course you could just:
$dt = previous(
datetime = DateTime-now(),
hour = 19
)-truncate( to = 'hour' );
But adding the truncate allows us to subclass easily:
package DateTime::Event::DateTime::Christmas
use strict;
use DateTime::Event::DateTime;
use vars qw(@ISA);
@ISA = qw(DateTime::Event::DateTime);
sub new {
return $_[0]-SUPER::new(
day = 25,
month = 12,
truncate = 'day'
);
}
So now we can:
$christmas = new DateTime::Event::DateTime::Christmas;
$next_christmas = $christmas-next()
Note: All methods revert to DateTime-now() if they're not given a
datetime parameter.
This module contains a free set of steak knives:
- DateTime::Event::DateTime::Christmas
- DateTime::Event::DateTime::NewYearsEve
and will include extra steak knives upon release.
Will this be useful to anyone other than me?
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, 15 Jul 2003, Ben Bennett wrote:
Ommissions from Date::Parse:
- July 14th will not be parsed (I don't have localized info on the
numeric suffixes)
How about you just assume /\d{1,2}\w+/?
Perhaps, I will play with it when the rest is finished. Input from
people who speak other languages would be appreciated. I think that
would be okay in French, I am a bit concerned about how it behaves
with non-Latin languages.
It works as long as they're using Arabic numerals. If people want to
write dates with native numerals (Chinese, for example) that's beyond the
scope of common parsing, and not your problem.
What happens in the event of input being in an unknown locale? As in we
don't know what locale this is in rather than we don't have locale
data for xy_XX.
Erm... maybe later I will make something that can deal with ambiguous
locales. That seems like a non-Simple.pm task (I realize that it
isn't that hard to do, but may be slow).
No, just default to the 'root' locale (which is really en_US). _That's_
simple ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, 15 Jul 2003, Ben Bennett wrote: We'd have to look at the _actual_ format strings to do this, but it's certainly possible. Ok, I will play around with this and see if all of the locales have understandable short forms. Actually, I was thinking that this would be done when generating the locale modules. It shouldn't be _too_ hard, I think. 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. Cool, I may add that in the future if needed. Again, see above. You're welcome to tweak the generator code in the DateTime::Locale CVS. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
On Tue, Jul 15, 2003 at 11:40:16AM -0500, Dave Rolsky wrote: On Tue, 15 Jul 2003, Ben Bennett wrote: Actually, I was thinking that this would be done when generating the locale modules. It shouldn't be _too_ hard, I think. Sorry, that was where I was intending to fiddle with, I just wanted to make sure it was possible to do it for all of the locales (or at least a reasonable number of them). Again, see above. You're welcome to tweak the generator code in the DateTime::Locale CVS. Cool. -ben
Re: Ambiguous years (what does 03 mean?)
John Peacock schreef: Given the date 02/11/03 in the locale en_US (so you can assume m/d/y), what year is that in? 3. Add the following code (modulo what you called the year variable): if (length($yr) 4) warn (Your year value is indeterminant. Performing SWAG[1]!); Why are years 1000 indeterminant? Eugene
Re: DateTime::Format::Simple and Indication of month/day/year or d/m/y in Locales...
Dave Rolsky schreef: On Tue, 15 Jul 2003, Ben Bennett wrote: 200210131:02 No! Egads :-) Actually I wasn't accepting the form 200210130102 either (I will accept 20021013T0102). Should I? Is the former form unambiguous? If so, you mighta s well accept it. 200210131:02 is (more or less) unambiguous: 2002-10-13T01:02. But 200210121:02 is ambiguous: 2002-10-12T01:02, 2002-10-01T21:02, 2002-01-01T21:02? Best not to accept either, I'd think. Eugene
Re: FW: [cpan #2958] AutoReply: DateTime-Set fails make test for recurrence
I think this is related to an older version of DateTime::TimeZone. I installed the latest from CPAN and it just worked. Did somebody else get errors with DateTime::Set? - Flavio S. Glock Hill, Ronald wrote: Hi Flavio, I thought you might want to know about this. Ron Hill Greetings, This message has been automatically generated in response to your bug report about DateTime-Set, a summary of which appears below. There is no need to reply to this message right now. Your bug in DateTime-Set has been assigned an ID of [cpan #2958]. Please include the string: [cpan #2958]
ICU data and date formats...
A bunch of the locales (e.g. ar_SY) have no date formats, but have other stuff defined so they pass the has_data() check. In this case I think they should inherit from their parent (ar). However, there are some base languages (e.g. az) which have no date format information defined but their sole child (e.g. az_AZ) has them. The problem in this case is that the dates defined by az_AZ are of the form dd.MM., but root is M/d/yy so simply inheriting the root one is probably incorrect. So I propose the following: A) If a locale (specified by language and territory) has no date format then it should inherit that of the language B) If a language has no date format then no date format can be determined. For the DT::F::Simple stuff that will mean that there is no default month and day ordering, so it will throw an error unless one is provided separately. Does this make sense? I think A can be implemented by simply changing the subclass not to generate a date_formats sub since it ISA the parent class. I have not looked to see if there is a similar issue with month and day names not being defined, but I assume that there is. I assume that a similar fix will be sufficient if there is a problem. Thoughts? -ben
Changable locale data...
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. -ben
Re: ICU data and date formats...
On Tue, 15 Jul 2003, Ben Bennett wrote:
However, there are some base languages (e.g. az) which have no date
format information defined but their sole child (e.g. az_AZ) has them.
The problem in this case is that the dates defined by az_AZ are of the
form dd.MM., but root is M/d/yy so simply inheriting the root one
is probably incorrect.
So I propose the following:
A) If a locale (specified by language and territory) has no date
format then it should inherit that of the language
B) If a language has no date format then no date format can be
determined. For the DT::F::Simple stuff that will mean that there
is no default month and day ordering, so it will throw an error
unless one is provided separately.
Does this make sense?
Why bother with this? If a language-only locale (like 'az') has no date
formats, that's not a bug or anything. It simply means that the language
is probably spoken in various places, each with different formats.
As long as the fact that everything defaults to 'root' (which is basically
'en_US') is well-documented, I don't see a problem.
What you're proposing would mean that for many locales, there would be
_no_ date formats, which will just cause random breakage when people try
to use something like $dt-strftime('%c'). Having this randomly throw
exceptions is not a good thing.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Changable locale data...
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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Another wrinkle...
It turns out that a handful of locales (e.g. af_ZA, en_ZA, fa, hr, hu, ja ...) have dates with the form y/m/d. So it looks like the value for the date component order (and the optional parameter to DT::F::Simple) should be a string that can take the 3 values: 'ymd' 'dmy' 'mdy' Does this make sense? -ben
Re: Ambiguous years (what does 03 mean?)
Eugene van der Pijll wrote: if (length($yr) 4) warn (Your year value is indeterminant. Performing SWAG[1]!); Why are years 1000 indeterminant? I was being [mostly] facetious. The format MM/DD/YY is very common, and mostly broken. The idea is that the end user needs to be hit with a high-voltage prod every time they use the common yet incomplete date format, in the hopes that they will eventually learn the lesson. One way to handle this (if the problem space is known) is to prompt for individual arguments for MONTH, DAY, CENTURY, and YEAR. In web forms, making the CENTURY be a dropdown list with 19, 20, 21, etc. will assist the user to no end in actually entering the proper information. 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: Ambiguous years (what does 03 mean?)
Dave Rolsky wrote:
I think the standard is something along the lines of:
if ($year + 50 ($current_year - 2000)) { $year += 1900 } else { $year += 2000 }
Except that this will probably be wrong when used to convert birthdates of
retirees (actual project I had to deal with, BTW). See:
http://www.dmi.uiuc.edu/y2k/window.htm
for a way to handle moving windows.
The two digit year format is so pernicious that it demands a warning in pretty
much all cases, and an error in any situation where the data is important.
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: ICU data and date formats...
On Tue, Jul 15, 2003 at 01:22:36PM -0500, Dave Rolsky wrote:
On Tue, 15 Jul 2003, Ben Bennett wrote:
[...]
As long as the fact that everything defaults to 'root' (which is basically
'en_US') is well-documented, I don't see a problem.
What you're proposing would mean that for many locales, there would be
_no_ date formats, which will just cause random breakage when people try
to use something like $dt-strftime('%c'). Having this randomly throw
exceptions is not a good thing.
Oh damn. My instrumented version of generate_from_icu was changing
the behvior so I was ending up with an empty %time_formats structure
that I thought would cause problems.
So it looks like your code is doing part A already and you are of
course correct that everything should inherit from root to make sure
that the strftime behavior is reasonable.
Sorry all,
-ben
DateTime::Format::Pg problem
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. [EMAIL PROTECTED] aboster]$ cat dt_test.pl #!/usr/local/bin/perl -w use DateTime; use DateTime::Format::Pg; use strict; my $str = '2003-07-14 09:37:33-07'; my $d = DateTime::Format::Pg-parse_datetime($str); print Dumper(\$d); [EMAIL PROTECTED] aboster]$ ./dt_test.pl The following parameter was passed in the call to DateTime::new but was not listed in the validation options: fractional_second at /usr/local/lib/perl5/site_perl/5.8.0/DateTime/Format/Builder/Parser/Regex.pm line 135 [EMAIL PROTECTED] aboster]$ Since there are warnings in the docs about setting a timezone, I have also tried instantiating the a DateTime::Format::Pg object with the server_tz set and then calling the parse_timestamptz function. The behavior is the same. (No surprise as this is the first parser tried by the more general function above.) This is DateTime::Format::Pg version 0.04. Thanks in advance, Alex PS: Here's hoping I haven't missed something really obvious and am making a public spectacle of it...
Re: DateTime::Format::Pg problem
fractional_seconds is deprecated... nanoseconds have to be specified separately. I dunno if Pg has been updated to use the new interface yet. -ben On Tue, Jul 15, 2003 at 12:30:39PM -0700, Alex Boster 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. [EMAIL PROTECTED] aboster]$ cat dt_test.pl #!/usr/local/bin/perl -w use DateTime; use DateTime::Format::Pg; use strict; my $str = '2003-07-14 09:37:33-07'; my $d = DateTime::Format::Pg-parse_datetime($str); print Dumper(\$d); [EMAIL PROTECTED] aboster]$ ./dt_test.pl The following parameter was passed in the call to DateTime::new but was not listed in the validation options: fractional_second at /usr/local/lib/perl5/site_perl/5.8.0/DateTime/Format/Builder/Parser/Regex.pm line 135 [EMAIL PROTECTED] aboster]$ Since there are warnings in the docs about setting a timezone, I have also tried instantiating the a DateTime::Format::Pg object with the server_tz set and then calling the parse_timestamptz function. The behavior is the same. (No surprise as this is the first parser tried by the more general function above.) This is DateTime::Format::Pg version 0.04. Thanks in advance, Alex PS: Here's hoping I haven't missed something really obvious and am making a public spectacle of it...
nmake test failure on perl 5.8.0 CVS version of datetime.pm
Hi All, Test report for the CVS version of datetime. Is there a better place to post test results other than on the newsgroup? Hope this helps. Ron Hill [snipped] t\13strftime..NOK 41# Failed test (t\13strftime.t at line 44) # got: 'Sep 7, 1999 1:02:42 PM' # expected: '1:02:42 PM Sep 7, 1999' # New locale: de t\13strftime..ok 75/126# New locale: it t\13strftime..ok 126/126# Looks like you failed 1 tests of 126. t\13strftime..dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 41 Failed 1/126 tests, 99.21% okay These tests failed for both 5.6.1 and 5.8.0 [more snippage] t\20infinite..NOK 11# Failed test (t\20infinite.t at line 53) t\20infinite..NOK 12# Failed test (t\20infinite.t at line 61) # got: '-2147483648' # expected: '2147483648' t\20infinite..NOK 13# Failed test (t\20infinite.t at line 61) # got: '-2147483646' # expected: '2147483648' t\20infinite..ok 37/37# Looks like you failed 3 tests of 37. t\20infinite..dubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 11-13 Failed 3/37 tests, 91.89% okay This is odd the infinite tests did not fail for perl version 5.6.1
Re: Ambiguous years (what does 03 mean?)
On Tue, 2003-07-15 at 22:13, Ben Bennett wrote: Given the date 02/11/03 in the locale en_US (so you can assume m/d/y), what year is that in? 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? I say by default, just use the user's input as gospel. You could try all sorts of things as a window for the rollover, but two-digit years are *always* context sensative. Under Date of Birth, the window would be 1903-2003. Under Indended date of travel, the window would be 2003-2102 (As hard as I wrack my brain I can't think of a time when I'd not be sure if it was a past or future event I wanted the date for.) Because of this, maybe the following would be the go: DateTime::Format::Simple-new( handle_two_digit_year = 'past' ) # two digit years are 1904-2003 DateTime::Format::Simple-new( handle_two_digit_year = 'future' ) # two digit years are 2003-2102 DateTime::Format::Simple-new( handle_two_digit_year = 1970 ) # two digit years are 1970-2069 (just in case there is a need) DateTime::Format::Simple-new( ) # two digit years are 00-99 by default And maybe: DateTime::Format::Simple-new( handle_two_digit_year = -20 ) # two digit years are (DateTime-now-year() - 20) to (DateTime-now-year() + 79) My $0.02. Cheers! Rick
Re: DateTime parse(), parser()
* Bruce Van Allen ([EMAIL PROTECTED]) [15 Jul 2003 04:55]: [...] 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; I'm yet to see a consistent method of handling errors in Perl modules. Whether an error is thrown or undef is returned, fall through is quite possible (eval). What do people think parsers should return if they can't parse? And what if they do parse, but DateTime doesn't want to create an object of the appropriate specification? Should we wrap our methods in evals and return undef? Should we just throw errors? [...] cheers, -- Iain.
