Howdy,
I'm integrating duration objects into an app I'm building, but have a
bit of a problem using DateTime::Duration objects. The problem is this:
Say that a user selects a duration of 2 hours for the duration in a
Web form and saves it. The next time the user accesses that Web form,
On Jan 8, 2006, at 4:13 PM, Rick Measham wrote:
David Wheeler wrote:
The normalization stuff in DateTime::Format::Duration gets us part
of the way there, but not quite, as if I say, 23 hours, 90
minutes, it will return 24 hours 29 minutes, which is not
quite the same as what
On Jan 7, 2006, at 3:49 AM, Rick Measham wrote:
Now, if perl had an '===' operator for 'identical' then we could
use that to determine if both durations are *always* equal (so
maybe we need to add a comparison function for it:
1 second === 10 nanoseconds
1 year
Maybe I'm just a knucklehead, but I started out thinking that
DateTime::Duration-compare() would return true if the two durations
were the same, and false if they were not. When that wasn't working,
I looked at the docs and could find nothing to say what it *does*
return. But I noticed
Just a quick question, maybe I just don't understand something. I
have code that compares new and old values of object attributes
before assigning the new value. If the attribute has not been
changed, I don't bother to assign. However, this doesn't work with
DateTime::Duration attributes,
On May 2, 2005, at 18:41 , Tim wrote:
p.s. Since Postgres has been mentioned already I'll mention MySQL :)
http://dev.mysql.com/doc/mysql/en/spatial-extensions-in-mysql.html
PostgreSQL geometric data types:
http://www.postgresql.org/docs/8.0/static/datatype-geometric.html
;-)
David
smime.p7s
On Apr 28, 2005, at 10:48 PM, Dave Rolsky wrote:
What I'd really like to see is some way to query both single events
and recurring events within a given timeframe, all in one query that
returns a sorted array of occurrences.
I haven't tried it (yet), but you might want to check out the INTERVAL
On Apr 28, 2005, at 11:05 PM, David Wheeler wrote:
I haven't tried it (yet), but you might want to check out the INTERVAL
data type in PostgreSQL.
http://www.postgresql.org/docs/current/static/datatype-datetime.html
Or, more precisely:
http://www.postgresql.org/docs/8.0/static/datatype
On Apr 29, 2005, at 10:51 AM, Dave Rolsky wrote:
Surely implementation of that data type is just a SMOP!
What would the data type look like, exactly? You might be able to
create it using DOMAINS in PostgreSQL.
http://www.postgresql.org/docs/current/static/sql-createdomain.html
Hehe. Actually,
On Oct 10, 2004, at 5:58 PM, Rick Measham wrote:
... I just think that DateTimeX looks too strange. It works for modules
whose namespace is all upper (like CGI, DBI, LWP etc), but looks a
little strange for namespaces like DateTime.
Seems to work fine for MasonX...
Regards,
David
On Jul 16, 2004, at 4:35 PM, John Siracusa wrote:
As for this:
$obj-start_date(format = '%B %d %Y at %T')
being nothing more than syntactic sugar for this:
$obj-start_date-strftime('%B %d %Y at %T')
Yes, that's my argument against it. And it's why dates are such a PITA
in Bricolage.
the
On Jul 16, 2004, at 2:01 PM, Dave Rolsky wrote:
Let me cut off this line of discussion, because I really, really,
really
hate this style of dual-purpose methods. The reason I dislike it so
much
is that it's impossible to distinguish between a mutator and an
accessor
that accepts arguments to
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 that is the most relevant to the
API
(e.g. day) It's
On Jul 15, 2004, at 2:40 PM, Dave Rolsky wrote:
$d-day(1) and friends should be the equivalent of $d-set(day = 1)
to make the interface consistent and obvious.
Hrm. I'm inclined to agree, I think. I like having separate accessors
and mutators but DateTime's current model:
$d-day; # accessor
On Apr 22, 2004, at 5:45 AM, Dave Rolsky wrote:
Objections? Comments?
My only objection to svn is that activitymail doesn't work with it.
Perhaps someone could convince the maintainer of that program to find
the tuits to port it, eh?
Otherwise, I'm thinking of moving my projects to svn, too,
On Apr 22, 2004, at 4:01 PM, Tim Bunce wrote:
I don't know what activitymail is, but I do know that svn.perl.org
sends emails for each commit (to a mailing list that corresponds to the
module being changed).
That's what activitymail does, but it sends the diffs from the (CVS)
commits, too,
On Apr 22, 2004, at 5:14 PM, Dave Rolsky wrote:
It's well worth the move, IMO.
Yeah, I think so, too. I'll check it out as soon as I have the tuits
and Ask gives me the a-ok.
Cheers,
David
On Apr 22, 2004, at 8:54 PM, Tim Bunce wrote:
I should have added that the emails include the diff.
As an attachment? That's what has distinguished activitymail over the
last two years or so.
David
On Feb 24, 2004, at 7:02 PM, Dave Rolsky wrote:
But I'm led to ask: Is
Module::Build really robust enough to switch from MakeMaker to
Module::Build?
You think MakeMaker is robust? Hahahahahaha
That's funny.
What Dave is trying to say is, yes, Module::Build is robust enough to
switch from
On Feb 24, 2004, at 8:42 PM, Rick Measham wrote:
Thankyou for a sensible response David. While MakeMaker's maintainer
and others may say long live Module::Build, I keep having trouble with
it whereas I've never had trouble with MakeMaker. Thus my question.
Yes, this was due to an oversight Ken
On Feb 24, 2004, at 9:44 PM, Dave Rolsky wrote:
I felt
uncomfortable telling them to wait for M::B 0.24 with no release
timeframe, because Ken went on vacation right after release 0.23.
Ken's on vacation _again_?? Damn!
D
On Feb 21, 2004, at 7:48 AM, Dave Rolsky wrote:
I found the discussion about stringification. The reason I took it
out of
the DateTime.pm code was that it made stack traces look quite wack.
I trust that's only true when you use a DT object in a stringification
context? Doesn't seem like much
On Feb 21, 2004, at 12:11 PM, Dave Rolsky wrote:
Well, right. But I'm talking about printing out a stack trace, ala
Carp
or Devel::StackTrace. It prints out subroutine arguments, which may
include objects. If the objects are stringify to something like
'2004-01-02 11:12:13' then that could be
On Feb 21, 2004, at 2:01 PM, Dave Rolsky wrote:
Hmmm, I guess not. At least, I couldn't get 'no overload' to do
anything
useful.
How much of a PITA is it to use overload::StrVal and
overload::Overloaded in Devel::StackTrace?
Not a PITA at all, I just liked the other solution even more.
This is
On Feb 21, 2004, at 4:56 PM, David Wheeler wrote:
Could Devel::StackTrace print out the names of objects and their
addresses some other way, to avoid problems when they happen to be
stringified?
Sorry, shoulda read the other followups, first. Sounds like Matt Sisk
has hit upon a great solution
On Jan 19, 2004, at 2:40 AM, Joshua Hoblitt wrote:
Because not everyone is connected to a network with access to a CPAN
mirror. And those people will hate you.
RTFM on Module::Install
Got tuits?
David
On Jan 16, 2004, at 7:55 PM, Joshua Hoblitt wrote:
I would do it the way we did it in DBD::Pg: Put it in t/lib:
Why not use Module::Install?
Because not everyone is connected to a network with access to a CPAN
mirror. And those people will hate you.
Regards,
David
On Jan 16, 2004, at 4:42 PM, Dave Rolsky wrote:
There's App::Info and Alien for detecting non-Perl dependencies, but
someone would have to code up the libgmp parts explicitly.
Well, Alien mainly exists as an idea in Arthur Bergman's head. (Maybe
he has been taken over by an alien?). It's goal is
On Jan 16, 2004, at 5:38 PM, Jonathan Leffler wrote:
Thanks for the pointer to App::Info - it looks interesting.
DBD::Informix already has to do a lot of stuff like that - and has
classes which supports its efforts. Integrating that into a App::Info
framework probably isn't too hard.
No,
use strict;
use POSIX qw(tzset);
print scalar localtime, $/;
{
local $ENV{TZ} = Asia/Tokyo;
tzset;
print scalar localtime, $/;
}
print scalar localtime, $/;
The question is, what does the third print statement print? Do I need
to call tzset again after the block?
TIA,
David
--
David
question from David a few months
ago?
Possibly. I had reported an issue with TZs not appearing to work on
Debian, but if you said exactly the above, I missed it. Sorry. I'm glad
to have the information now!
Cheers,
David
--
David Wheeler AIM: dwTheory
[EMAIL
-- except perhaps on Debian. Are you saying that if I
want the setting of TZ to portably affect, e.g., localtime, that I need
to always POSIX::tzset() after I do it? Seems a waste to load all of
POSIX.pm just for that...
Cheers,
David
--
David Wheeler AIM
it for you, passing your default arguments, and
returning the result. In fact, make it a code reference, and you will
for all practical purposes have a curried version of the constructor!
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED
and post a test script to demonstrate the issue?
Mark? Scott?
Thanks,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
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
is that this should greatly speed up a common code
path.
Sounds pretty sensible to me.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Unix variants, or VMS, QNX, or other weird things like
that.
Testing on Mac OS X:
Other than this:
Warning: the following files are missing in your kit:
META.yml
Please inform the author.
DateTime looks good -- all tests pass, etc.
Regards,
David
--
David Wheeler
On Friday, June 13, 2003, at 10:59 AM, David Wheeler wrote:
Testing on Mac OS X:
Other than this:
Warning: the following files are missing in your kit:
META.yml
Please inform the author.
DateTime looks good -- all tests pass, etc.
Uh, that's Perl 5.8.0.
David
--
David Wheeler
really add anything to the FAQ for most readers.
Tried Pod::Simple::HTML? We should all nicely ask Sean to get it
finished, now that his new book is pretty well done.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED
that subclassing is one of Sean's goals for the Pod::Simple
classes. I say we bug him about it. ;-)
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://kineticode.com/ Yahoo
, for the code
that Sean eventually wants to develop there, and which should be
subclassable. I know that Graham Barr is also anxiously waiting for
Sean to write the new P::S::HTML.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED
a hitch.
Mac OS X 10.2.4
Perl 5.8.0
CPANPLUS 0.042
DateTime::TimeZone 0.08
DateTime 0.06
David
PS: I've noticed in the past that Mac OS X 10.1 seemed to ignore the TZ
environment variable -- could that have been part of the problem?
--
David Wheeler AIM: dwTheory
ships in the core.
It hasn't stopped DBI from gaining wide acceptance. And only recently
has a pure perl DBI been introduced. And it's used far less, of course.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
.
month[$date-month_num] vs. $date-month both return January
I think that this will be resolved by:
month[$date-month_0] vs. $date-month both return January
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
,
or
call a user-defined callback).
And die with an exception object as the default, yes?
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
$$dth-clone( hour = 17 ) or equivalent
# internal gymnastics, and then stores the resulting object.
Yes, although if someone expects the object reference to be the same,
they'll get a rude surprise.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED
of Exception::Class.
However, it'd probably be ideal to allow users to determine how to deal
with these things, a la DBI's approach.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http
by
default.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
, along with a PrintError, just for
those who actually like warnings.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
it's like that except for day of week. Hmm, I will ponder
this
some more.
Nah, Matthew is right, I think Just do it. The only time you shouldn't
do it is if we override localtime and want to stringify it like
Time::Piece does.
David
--
David Wheeler AIM
you call today Elevenday or something ;)
I wouldn't rule that out when it comes to other calendars.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo
-month, $ship_d-day
);
One of the most important methods that Date::ICal is missing, IMO, and
that we should grab from Time::Piece and put into the core, in my
opinion, is strftime. I *love* that method!
my $t = localtime;
print $t-strftime(%Y/%m/%d);
David
--
David Wheeler
stringification. If the DBD handles it,
fine, but I think it'd be ideal to design it in such a way that the DBD
didn't have to do anything more than specify the datetime string format
it needs (in strftime format, most likely), and have the DateTime
object do the rest.
Regards,
David
--
David
, and I'm probably just getting way too far ahead of
myself. ;-)
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
54 matches
Mail list logo
