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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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_
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'
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
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:
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,
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
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
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'
#
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
* 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
28 matches
Mail list logo
