Re: DateTime bug default timezone
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 unpredictable results: [snip] That's why there is an eom_mode (end of month mode) parameter for the DateTime::Duration constructor, which allows you to control how adding months is handled. I think the parameter got renamed to end_of_month. Excellent. - Bruce In your examples, you showed a business month=30 days calculation. Should we have such a 'business' mode? Existing modes are wrap (the default), limit, and preserve: Assuming adding X months to month M, day D: wrap will give D-1 days after the first of month M+X limit will give month M+X with the day being the earlier of D and the last day of the month preserve will give the last day of month M+X if D is the last day of M; otherwise it will give the same result as limit 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 and seem to recall that the above just coredumps on some platforms.
Re: DateTime bug default timezone
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 idea came from a perlmonks discussion. I've got positive reports from mac, pc, linux and sun users. I'll look into perl5-porters... - Flavio S. Glock
Re: DateTime bug default timezone
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 and seem to recall that the above just coredumps on some platforms. There is something here: http://aspn.activestate.com/ASPN/Mail/Message/1395647 On Mon, Oct 14, 2002 at 02:49:54PM +0300, Jarkko Hietaniemi wrote: It seems that '2**1' produces zero with gcc 3.2.1 in Tru64 5.1A, which is of course a bug to itself, but at least this pack.t test [more] - Flavio S. Glock
Re: truncate() semantics
If I'm truncating a date to 'month', is because I want a date with
'integer-months'.
Just like if I truncated a number to 'integer' - I get an integer
number, isn't it?
See also:
http://www.redhat.com/docs/manuals/database/RHDB-7.1.3-Manual/sql/functions-datetime.html#FUNCTIONS-DATETIME-TRUNC
[...]
The return value is of type timestamp with all fields that are less
than the selected one set to zero (or one
[...]
SELECT date_trunc('hour', TIMESTAMP '2001-02-16 20:38:40');
Result: 2001-02-16 20:00:00+00
SELECT date_trunc('year', TIMESTAMP '2001-02-16 20:38:40');
Result: 2001-01-01 00:00:00+00
- Flávio S. Glock
Re: truncate() semantics
On Fri, 14 Mar 2003, fglock wrote: If I'm truncating a date to 'month', is because I want a date with 'integer-months'. Just like if I truncated a number to 'integer' - I get an integer number, isn't it? Yeah, I'll fix it. I'm not sure exactly what I was thinking ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Date::Ethiopic Announcement
Greetings, After much feature creep, I've finally released this morning a version of Date::Ethiopic. It is derived from Date::ICal but assumes dates passed to the object as args are in the Ethiopic calendar context. A Gregorian context can be set with a calscale = gregorian argument and the date args will be converted into the Ethiopic calendar system. The class also has a toGregorian method which returns a Date::ICal object with Gregorian dates. There is also a calscale method to check the calendar context of the object when it might be unknown. I recommend these two methods for other packages that also work with non-Gregorian systems. They offer a way to normalize a date for additional conversions, for example: my $ethio = new Date::Ethiopic ( $chinese-toGregorian ); Ah.. a new Date::Ethiopic object can be instaniated from a Date::ICal object, I recommend that too. I haven't been able to keep up with the datetime list during the last year and am out of touch with the latest school of thought on time classes for Perl. I anticipate working on the package regularly and would like to follow standards to the extent that they are available. Using the Date::ICal base class was a conscious attempt at just this. Date::Ethiopic I've begun to suspect may no longer be the preferred name choice. Please let me know what naming conventions are recommended. thanks, /Daniel
