On Tue, 11 Mar 2003 10:46:32 -0800, [EMAIL PROTECTED] wrote:
On Monday, March 10, 2003, at 07:10 PM, Dave Rolsky wrote:
On Sat, 1 Mar 2003, Bruce Van Allen wrote:
I agree with these thoughts and principles, but thinking of months as
discrete units also has complications, as you say, with weird
Yitzchak Scott-Thoennes wrote:
use constant INFINITY = 100 ** 100 ** 100 ;
use constant NEG_INFINITY = -1 * (100 ** 100 ** 100);
I remember this (how to produce an numeric infinity) coming up on
perl5-porters and seem to recall that the above just coredumps on some
platforms.
The
Yitzchak Scott-Thoennes wrote:
On another topic, just below add_duration in DateTime.pm, I see this:
use constant INFINITY = 100 ** 100 ** 100 ;
use constant NEG_INFINITY = -1 * (100 ** 100 ** 100);
I remember this (how to produce an numeric infinity) coming up on
perl5-porters
On Sat, 1 Mar 2003, Bruce Van Allen wrote:
I agree with these thoughts and principles, but thinking of months as
discrete units also has complications, as you say, with weird
unpredictable results:
# per above examples:
01:00 31 December 2002 + 2 months = 01:00 31 February 2003 # NO
#
I'd say that the same applies .. add one month:
01:00 26 January 2003 + 1 month = 01:00 26 February 2003
01:00 26 February 2003 + 2 months = 01:00 26 April 2003
Hmm, I'm sure there are cases where people want the other implementation,
though.
I think that arises from fuzzy thinking.
On Saturday, March 1, 2003, at 07:21 AM, [EMAIL PROTECTED] wrote:
I'd say that the same applies .. add one month:
01:00 26 January 2003 + 1 month = 01:00 26 February 2003
01:00 26 February 2003 + 2 months = 01:00 26 April 2003
On Friday, February 28, 2003, at 10:56 PM, Dave Rolsky wrote:
Hmm,
On Thu, 27 Feb 2003, Rick Measham wrote:
I think if I add 'one day' then the time is the same, regardless of DST
cusp. Only the day increases.
If I add '24 hours' then at the DST cusp the time would change, as would the
day.
Ok, that's easy. But what about months?
-dave
At 11:28 PM -0600 28/2/03, Dave Rolsky wrote:
On Thu, 27 Feb 2003, Rick Measham wrote:
I think if I add 'one day' then the time is the same, regardless of DST
cusp. Only the day increases.
If I add '24 hours' then at the DST cusp the time would change, as would the
day.
Ok, that's easy. But
On Sat, 1 Mar 2003, Rick Measham wrote:
Ok, that's easy. But what about months?
I'd say that the same applies .. add one month:
01:00 26 January 2003 + 1 month = 01:00 26 February 2003
01:00 26 February 2003 + 2 months = 01:00 26 April 2003
Hmm, I'm sure there are cases where people want
Dave Rolsky wrote:
So does anybody reading this object to me changing the default time zone
to UTC? I think UTC is better than floating here simply because it's
easier to explain.
I understand that a 'floating' date object has less information on it
than a 'UTC' date object, since the
On Wed, 26 Feb 2003, Eugene van der Pijll wrote:
If $object-can('time_zone'), the _utc_rd_values should be interpreted
as 'utc', but you can just take the $object-timezone (and clone it?)
and use that.
True. Time zone objects are actually singletons, so no need to clone
anything.
Of
On 27/2/03 10:33 am, Dave Rolsky at [EMAIL PROTECTED] spake thus:
This has to do with the internal implementation, which is to add things to
the UTC Rata Die days and seconds values, and then re-calculate the local
time. If someone adds hours, minutes, or seconds explcitly, this is
definitely
12 matches
Mail list logo
