On 1/18/03 7:21 PM, Dave Rolsky wrote:
On Sat, 18 Jan 2003, John Siracusa wrote:
Just as an aside (or maybe not?) I've always wanted DB-specific date parsing
and formatting functionality to hang off of the $dbh, just like quoting
does. It's much easier to keep code database-neutral this way
On 1/19/03 12:26 PM, Dave Rolsky wrote:
On Sun, 19 Jan 2003, John Siracusa wrote:
That's a nice idea, but people may want to use these modules without using
DBI
And so they can. What's stopping them?
Nothing. I'm just saying that the API needs to work both for standalone
use
On 3/26/03 12:33 AM, Dave Rolsky wrote:
On Tue, 25 Mar 2003, John Siracusa wrote:
Hrm, well, I'd actually be happy (for my purposes) with simply storing
fractional seconds as an integer somewhere. I don't care if fractional
durations are allowed, or if fractional seconds are used in date
DateTime::TimeZone::Local (from CPAN) is missing:
use File::Spec;
But later calls File::Spec-splitpath(...), resulting in the error:
Can't locate object method splitpath via package File::Spec at
/Library/Perl/DateTime/TimeZone/Local.pm line 44.
-John
On 7/13/03 6:47 AM, Eugene van der Pijll wrote:
1/20/2002 1:02 p.m. (okay, maybe a Euro-mode for dd/mm/ :)
A parser that can parse this format correctly should not be called
Simple. As you say, it has to have a US and a Euro mode at least; the
default DateTime parser should be simple
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 recognises the sorts of dates you come across. I mostly
come
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
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
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()
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.
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
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:
-
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
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
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
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
Looks good so far! :)
- Suggestions of additional formats to parse would be greatly
appreciated
...or so you'd think! +/-infinity...pretty please? :)
-John
On Friday, July 18, 2003, at 11:17 PM, Ben Bennett wrote:
- Suggestions of additional formats to parse would be greatly
appreciated
Ooo, and didn't you also forget now?
-John
On Friday, July 18, 2003, at 11:20 PM, Ben Bennett wrote:
I am not a big fan of DateTime::Format::Simple either. My best
suggestions are:
DateTime::Format::Basic
Common
Generic
Localized
I'd say it's between Basic and Common. A more accurate
I was profiling a database-backed mod_perl application recently. A
particular request was taking several seconds to complete. At first I
thought the database was the bottleneck, but the request included only
one database query, and that query completed in about 300msec when run
from a
On 8/4/03 12:26 AM, Dave Rolsky wrote:
# ... includes args: year, month, day, hour, minute, second
DateTime-new(...): 16 wallclock secs @ 687.29/s
(14.48 usr + 0.07 sys = 14.55 CPU)
This does a lot of work, including calculating both UTC local times,
which involves calculating leap
On 8/4/03 10:10 AM, John Siracusa wrote:
On 8/4/03 12:26 AM, Dave Rolsky wrote:
# ... includes args: year, month, day, hour, minute, second
DateTime-new(...): 16 wallclock secs @ 687.29/s
(14.48 usr + 0.07 sys = 14.55 CPU)
This does a lot of work, including calculating both UTC local
On 8/4/03 1:25 PM, Ben Bennett wrote:
Why not make your module be lazy about whether or not it creates a
DateTime?
I thought of that, but I also use the act of creating a DateTime object to
check the validity of date attributes. Anyway, I think there's room for
DateTime-new() optimization even
On Friday, August 8, 2003, at 10:21 PM, Joshua Hoblitt wrote:
This is the 'decorator infrastructure' that I've been whining for.
It's kind of a melting pot for 'add-ons' or 'plug-ins'. The idea is
to throw DT, DT::Cache, DT::Foo, DT::Validator, etc. into the 'pot'
and end up with a factory
On Sunday, August 10, 2003, at 08:08 PM, Dave Rolsky wrote:
On Sun, 10 Aug 2003, John Siracusa wrote:
We have enough constructors as it is.
Well that's not my fault :) If, for whatever reason, you're going to
limit DateTime to N constructors, they should be the N most likely to
be used. Do you
On Sunday, August 10, 2003, at 10:24 PM, David Wheeler wrote:
On Sunday, August 10, 2003, at 07:17 PM, John Siracusa wrote:
Obviously, you need currying. See Perl 6. Or create your own
subclass with its own now() method that passes the argument for you.
Or create a function that calls
On Sunday, August 10, 2003, at 08:59 PM, Joshua Hoblitt wrote:
If you only have a year and day of year, then having a
from_day_of_year
constructor saves a _lot_ of calculation that end users have to do.
OTOH,
having to do 'DateTime-now(time_zone = local)' isn't very onerous
at
all.
If you need
On Sunday, August 10, 2003, at 01:34 PM, Dave Rolsky wrote:
On Sun, 10 Aug 2003, John Siracusa wrote:
...speaking of which, is there any chance DateTime-now() can be
changed to
default to the local time zone? It seems to me that now probably
means
now, here most of the time. I don't have
On Sunday, August 10, 2003, at 09:40 PM, Dave Rolsky wrote:
...unless that's the only way you will *ever* call now()! :)
Seriously, who is calling now() *without* time_zone = 'local'
arguments? I haven't done so yet, and would like to hear some
examples
of this usage.
Me, because I know that
On 8/26/03 2:10 PM, Eugene van der Pijll wrote:
* You might want to show some date math:
$dt1 = DateTime-now();
# One week ago:
$dt2 = $dt1-clone-subtract( weeks = 1);
print $dt2-datetime, \n;
...except you almost certainly want to do this:
$dt1 = DateTime-now(time_zone =
On 10/7/03 12:42 PM, Dave Rolsky wrote:
On Tue, 7 Oct 2003, Bill McCormick wrote:
Where is it? I checked a few mirrors and can't seem to find it.
Patience, young jedi. It takes a few hours, at least, for new uploads to
propogate to all the mirrors.
For the code it is time to propagate as
On 2/10/04 12:17 PM, Dave Rolsky wrote:
I should add a section to the docs on this so that people know what to
expect.
Yes, please do, because I am eternally confused by this :)
-John
On 2/12/04 1:36 PM, Dave Rolsky wrote:
On Tue, 10 Feb 2004, John Siracusa wrote:
On 2/10/04 12:17 PM, Dave Rolsky wrote:
I should add a section to the docs on this so that people know what to
expect.
Yes, please do, because I am eternally confused by this :)
There are some docs already
On 2/21/04 3:49 PM, Ben Bennett wrote:
If I remember correctly the argument against auto stringification was
that it made debugging harder.
Speaking of difficult debugging and DT, every time I feed something to
Data::Dumper that contains a DT object (or several) I cringe at the giant
output. I
On 2/21/04 4:33 PM, Dave Rolsky wrote:
On Sat, 21 Feb 2004, John Siracusa wrote:
Speaking of difficult debugging and DT, every time I feed something to
Data::Dumper that contains a DT object (or several) I cringe at the giant
output. I don't suppose there's any way to avoid that...
Nothing
On 7/15/04 5:55 PM, David Wheeler wrote:
I kind of like it, but only in environments where attributes are virtually
always READ, and rarely WRITTEN. So maybe it should be:
# Perl-style
$d-day; # accessor
$d-day(1); # mutator
Or:
# Java-style
$d-get_day; # accessor
On 7/16/04 5:01 PM, Dave Rolsky wrote:
On Thu, 15 Jul 2004, David Wheeler wrote:
Has a different naming convention for the two types of methods. I kind
of like it, but only in environments where attributes are virtually
always READ, and rarely WRITTEN. So maybe it should be:
# Perl-style
On 7/16/04 5:38 PM, David Wheeler wrote:
I've been fond of this argument myself, Dave. And I like having
separate mutators. But it's extremely common among Perl modules, and
really no different than the idea of true attributes. Using lvalue
subs, for example, one could:
$d-day; #
On 7/16/04 5:58 PM, David Wheeler wrote:
On Jul 16, 2004, at 2:52 PM, John Siracusa wrote:
And I cringe at APIs with 50 methods that begin with set_ and 50 more that
begin with get_. I have to mentally filter out the prefix noise when trying
to look up methods based on the part
On 7/16/04 9:15 PM, Dave Rolsky wrote:
(Anyway, ymd() isn't a get/set method at all, is it?)
It's a _get_ method. You're retrieving information from the object,
right? It's just not getting a single attribute.
When I questioned the prevalence of accessors that take arguments to affect
what
On Wed, 1 Dec 2004 12:28:35, Dave Rolsky [EMAIL PROTECTED] wrote:
I strongly dislike combined get/set methods, and they won't appear in
DateTime.
I recall that discussion from a while back but I don't remember your
reasons. Can you briefly reiterate them?
-John
On Wed, 1 Dec 2004 13:23:24, Dave Rolsky [EMAIL PROTECTED] wrote:
If someone gets local to work on Win32, it might be considerable. Until
then, it's not.
Ooo, a glimmer of hope! :) Too bad I don't do any Perl on Win32hrm.
-John
On Thu, 2 Dec 2004 13:02:16 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Ron Hill wrote:
Actually I run the reports on the first of the month for the previous
month so I had to do this
my $month = DateTime-today-truncate(to = 'month')-subtract(months=1);
[...]
This one behaves better - it
I filed this bug on DateTime::Format::Pg about a month ago but I'm not sure
Claus saw it.
http://rt.cpan.org/NoAuth/Bug.html?id=8516
Basically, it looks like the internal subroutine _fix_second() is missing
from the module. When it gets called as part of the public parse_time()
method,
On 2/28/05 9:42 AM, Geoffrey Young wrote:
DateTime objects are _huge_ for non-UTC timezones. consider:
[...]
print Dumper $dt;
I always just assumed that those giant structures exist once in memory and
are simply referenced by each DT object. I never bothered to actually
check, but c'mon,
On 2/28/05 1:26 PM, Dave Rolsky wrote:
On Mon, 28 Feb 2005, Geoffrey Young wrote:
The hugeness is the DateTime::TimeZone object, not DateTime itself.
Those are all singletons, so you only pay the price once per time zone.
ok, but how does that affect storable-style serializations? I noticed
On 3/15/05 11:54 PM, Cees Hek wrote:
I sent a bug report and patch to this list back in January [1]
regarding DateTime::Format::Pg, and I never received a response. Just
wondering if this slipped through the cracks. In the meantime, I have
logged this as a bug in rt.cpan.org [2].
I think
On 3/17/05 2:39 AM, Daisuke Maki wrote:
If there's nobody else, I don't mind being the maintainer, except I
doubt that I'll be doing much more than maintenance (as opposed to
active development). I should be able to respond in time in cases like
these, though.
Claus, the module is pretty
On 6/15/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Also, I think we may need to consider serious backwards incompatibility in
the future of DateTime.pm (possibly via a new namespace like DateTime2) to
really clean this up, but that'll wait til I'm less tired ;)
Just break it. DateTime's nowhere
On 7/5/05 7:04 AM, Eric Cholet wrote:
A while ago we did some profiling of an app that uses DateTime
extensively and found out that most of the time is spent in
Params::Validate. I understand this is somewhat of a religious issue,
but in this case it's a net loss for us: the params have been
On 7/7/05 12:12 AM, Rick Measham wrote:
Dave Rolsky wrote:
DateTime::Shim
DateTime::Trampoline
DateTime::ThinShim
DateTime::Proxy
DateTime::Diet - not awful but a little cute, methinks ;)
Of the above, I still like DT:Diet.
If you want something less cute/more serious how
On 7/23/05 3:35 AM, Rick Measham wrote:
If you read the code, you'll notice that I have a utc_rd_values method
as the math overload needs to be passed an object that 'can' call this
method.
Why not just override can() and delegate to DateTime proper?
-John
On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote:
Does anyone object to adding Math::BigFloat as a
prereq?
What are the performance/memory implications? I don't object to the prereq,
but I would like to know if we're in for any new speed/bloat issues. (I
only really care about per-object
On 8/16/05, Dave Rolsky [EMAIL PROTECTED] wrote:
So it turns out that DT.pm has basically been buggy with regards to date
math for any timezone with a DST change basically forever.
The problem is that sometimes people want to do math in terms of the local
time (the clock display time) and
On 8/16/05 8:01 PM, Rick Measham wrote:
add_calendar() (aliased to add()) sounds like a good name for the old
behaviour (local for ymd, UTC for hmsn) as we're adding according the
the calender.
I was thinking add_calendar() would be local for ymd and hmsn...but maybe
I'm confused. Basically,
On 8/16/05 8:14 PM, Rick Measham wrote:
I'd like to hear comment on stripping out lots of the methods currently
in DateTime and have them moved to decorator modules -- as this will
allow users to load what they want and only what they want in the way of
functionality.
Fine with me, as long as
On 1/11/06 3:43 PM, Dave Rolsky wrote:
What might be useful would be date-only objects, maybe as DateTime::Date or
something like that.
Speaking of this, anyone know of any nice *time*-only CPAN modules? If not,
how about a DateTime::Time? Maybe DateTime could just aggregate
DateTime::Date
57 matches
Mail list logo
