Re: [Fwd: DateTime::Duration comparisions]
On Fri, 14 Nov 2003, Jonathan Swartz wrote: I guess this boils down to four choices: 1) give an arbitrary answer 2) give a reasonable answer that may depend on the current time (add both durations to the current time and compare the resulting times) 3) give an answer if it is correct for all times, throw an exception otherwise 4) always throw an exception The current behavior is (1). I still favor (2), because it never throws an exception. The problem with (3) is that if you write code that compares arbitrary durations, it will work most of the time (e.g. during testing) but will occasionally throw an exception (e.g. once you're in the wild). It also seems more complicated to implement and document, though maybe not by much. I agree. Working quietly most of the time and occasionally throwing an exception that will be hard to explain (Duration exceeds fuzzy comparison limits) is not a good behavior. I don't mind the idea of adding a compare() class method that accepts a base datetime and uses DateTime-now, per Rick's suggestion. Overloading comparison to explicitly die also seems reasonable. It's annoying the first time it happens, but as I said in my Industrial Strength Perl presentation, it's better to die before you've screwed up all your data than afterwards. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone issues...
On Thu, 13 Nov 2003, Joshua Hoblitt wrote: Seriously, I'd like to eventually speed up/slim down the time zone stuff but just getting it working took an enormous amount of development effort. Making a super-fast whiz-bang version that still works is not trivial. Maybe we should ask around to try and determine the level of interest in using DT::TZ::* under mod_perl. If it's high we can apply for a linuxfund or TPF grant to fund Dave. Of course those that have a _financial_ interest in this can fund Dave directly... There's definitely interest. I do a lot of mod_perl app development myself, and I know that there are various other web app type places using the DateTime code. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone issues...
On Thu, 13 Nov 2003, Matt Sisk wrote: Since the time zone classes are generated, it'd be possible to generate XS code instead of Perl. Patches or a shipment of tuits would be extremely welcome. The timezone modules use lots of spans, correct? No, it's just a big data structure (an array of arrays). Each part of the big array represents a span, but it's not actually a DateTime::Span object. That wouldn't provide any added functionality in this case. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone issues...
On Thu, 13 Nov 2003, Matt Sisk wrote: Matt Sisk wrote: I have not verified this, but IF there is a lot of overlap of spans between various timezones, perhaps a 'span registry' could be shared between all the zone modules, thereby avoiding duplication of span objects. I just ran a quick check on TZ 0.2505: TZ module count: 367 Span count: 16969 Crunched: 9333 If you reuse duplicat span arrays by reference, you shave the memory footprint by approximately 45%. But that only applies when you load _all_ the zones How would these be shared if you only wanted to load 10-20 zones, or even 150 zones? It seems like the overhead of determining what is shared would outweigh the savings. Do you have any idea of how to implement this in a way that doesn't require all the zones to be loaded up front, because I can't think of one. I like the idea of sharing the data somehow though. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone issues...
On Thu, 13 Nov 2003, Matt Sisk wrote: Now I'm starting to think we can have our cake and eat it too vis-a-vis unique key generation for the spans. If you don't mind, I'll take a crack at the templating in the tz module generation script to construct the modules sharing the common data structure. Go for it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone issues...
On Thu, 13 Nov 2003, Rob Mueller wrote:
./perlbloat.pl 'use DateTime::TimeZone; $TZ{$_} =
DateTime::TimeZone-new(name = $_) for (DateTime::TimeZone::all_names)'
use DateTime::TimeZone; $TZ{$_} = DateTime::TimeZone-new(name = $_) for
(DateTime::TimeZone::all_names) added 12.7M
But of course you don't actually need all of those time zones. There are
quite a number of time zones that only have historical interest, for
example. Then there's the ones for various South Pacific islands, the
antarctic, etc.
So if you just loaded the ones you _needed_, it'd use a lot less memory.
Having a look at the code, I noticed that each timezone has it's own class,
and also a lot of data in perl structures. I'm not really sure why the
timezone classes were developed this way, it seems fine for a simple case
where you only need a couple of timezones, but in a case where you can
possibly be using ANY timezone in the same script, it seems a HUGE overhead
in memory and time to have to load all those structures into memory.
Patches welcome ;)
I'm not sure how else we could provide an accurate and complete view of
the time zone database data, other than generating Perl modules. We can't
rely on the database being present on any given system, much less being up
to date. The C-level API makes it pretty hard to reasonably do something
like convert a datetime from one zone to another, because it's all
controlled by one environment variable.
Plus that probably doesn't even work on non-Unixy/POSIXy systems.
Remember, Perl runs in a lot of places, and there's no reason these
modules shouldn't work in all of them.
In the end, we ended up going with the POSIX timezone related calls.
Although they're pretty hacky, they give us what we want (a seconds offset
from GMT for a given timezone name at a particular time) in a simple, quick
interface without needing 13M of overhead!
Right, but that's _all_ you wanted.
We're fine using our POSIX solution now, but I thought you folks might be
interested in this feedback - we chatted about it with Rick Measham at Perl
Mongers yesterday and he asked if we could provide this summary. It's
probably a good idea to keep web app developers in mind as you develop the
DateTime namespace, since it's a place where a lot of date/time calcuations
in Perl are required.
I do a heck of a lot of web dev, and I've used DateTime and the time zone
classes without any problems.
For example, you could just preload the time zones that your current users
are using, which would almost certainly be a small fraction of all
possible zones.
Since the time zone classes are generated, it'd be possible to generate XS
code instead of Perl. Patches or a shipment of tuits would be extremely
welcome.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [Fwd: DateTime::Duration comparisions]
On Tue, 11 Nov 2003, Max Maischein wrote: I saw in the CHANGES file that you added some other delta_* methods, but didn't find them in the documentation, so I don't know about these, and was too lazy to delve into the source for this :-) These are for DateTime objects. I'm now regretting the fact that both classes have delta_* methods. Sigh ... I wrote a test file that shows some ugly bugs when dealing with my naive comparision, most notably that ($dt-$dt)-is_zero() is false. I don't know why you implemented is_zero() that way, so I can't propose any good change. My approach would be to make is_zero() not only check the sign but also check whether all values are zero. Yeah, the is_* bits for durations are all screwed up. I'm considering removing them, because I'm not sure we can fix them and still do interesting thing with durations. DateTime::Duration problems on the mailing list, but I saw that you considered removing the comparision operators completely from DateTime::Duration - I think this would be bad, but I only ended up DateTime::Duration has never had comparison methods or overloading, so this would be difficult to remove ;) looking at DateTime::Duration, as I could not find an easy way to look at two DateTime objects and find out which one was later, as comparision for those also isn't implemented (or, once again, I'm too stupid to read the docs properly). Now I'm really confused. DateTime.pm objects have _always_ had a compare method, plus they overload comparison operators. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [Fwd: DateTime::Duration patch]
On Tue, 11 Nov 2003, Max Maischein wrote:
after some thinking about how to compare the inconvertible units, I
came up with an ugly hack that will work for most cases - the border
cases where it fails, are not yet detected, but I'm working on that. The
patch passes all my ad-hoc tests, I'll run it later against the DateTime
test suite.
You can't possibly detect the border cases because they only exist in the
context of a base datetime to which the durations are added. That's the
fundamental problem of trying to compare durations.
sub _normalize_sign {
my $self = shift;
my $minutes = $self-{minutes};
# A day is longer than (or equal to) 23 hours,
# a month is longer than (or equal to) 28 days a 24 hours, as DST is
never in february:
DST changes may not occur in February, but time zone offset changes can,
because these can occur due to legislation.
$minutes += $self-{days} * 23 * 60;
$minutes += $self-{months} * 24 * 60 * 28;
$self-{sign} = 0 = $minutes;
};
This is a vague approximation that won't work in all cases. How would we
document this? It's incredibly complicated to explain.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::TimeZone issues...
On Thu, 13 Nov 2003, Rob Mueller wrote: The only way really to provide a fast (to initialize, and access) timezone DB is to either provide a DB (e.g. CDB, SDBM, etc) with the module, or have something in the make process that creates such a DB based on the DBM modules available on the user's system (or, as you mentioned, use structs with XS). Sounds great. I welcome patches and/or funding and/or a time machine so I can develop these ;) Seriously, I'd like to eventually speed up/slim down the time zone stuff but just getting it working took an enormous amount of development effort. Making a super-fast whiz-bang version that still works is not trivial. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: comparing durations
On Sat, 8 Nov 2003, Jonathan Swartz wrote: I was trying to compare two durations, and came up with some surprises. DB1 use DateTime; DB2 $hour = DateTime::Duration-new(hours=1); DB3 $minute = DateTime::Duration-new(minutes=1); # Try comparing $hour and $minute DB4 print ($hour $minute) 1 # Wh?? You just compared the numeric values of the two refs. DB10 $d4 = $minute - $hour; DB11 print $d4-is_positive 1 # Wha?? I think I need to rework this class a little bit. The is_negative/positive/zero methods all make sense for durations constructed via new(), because they are not allowed to mix positive and negative units. But by using the add subtract methods/overloading, it is possible to construct an object which has both. One solution would be to simply make these methods return false for objects which we can't be sure about (anything which has had math done to it and now has mixed units), so both is_positive and is_negative would return false. The other might be to simply remove these methods, since I'm not sure how useful they are. I couldn't find anything about this in the documentation. I can understand after some reflection why you shouldn't be able to compare durations (e.g. how would you compare 30 days to 1 month), but it seems like this should be documented, and using comparison operator should fail. Let me know if I'm missed something obvious... Well, comparison fails because it's not overloaded at all, but I'll add an explicit note about that to the docs. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: style question about passing durations
On Sun, 9 Nov 2003, Jonathan Swartz wrote: Say I've got a function that takes a duration. I could 1) require the user to do DateTime::Duration-new(...); 2) take a listref argument containing the params, e.g. [days=1] and do the creation myself 3) be flexible and take either argument, distinguishing the two by isa() Any advice from others that have written APIs using durations? DateTime.pm itself just has two methods in each case. So we have add(), which takes raw parameters, and add_duration() which takes an object. The former is very simply syntactic sugar for the the latter. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Format
On Thu, 6 Nov 2003, Joshua Hoblitt wrote: Would this be better as a decorator that adds a format_datetime method? (decorator setup) DateTime::Format=Pg print DateTime-now-format_datetime 2003-11-01 06:34:35+ Well, people using this might very well want to have DateTime act as a translator between two data sources which need to exchange info, like two different DBMSs. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: parse_datetime and format_datetime
On Wed, 5 Nov 2003, Matt Sisk wrote: Just out of curiousity...why the '_datetime' suffix on these methods? Isn't that redundant? Or was it assuming that these methods might be showing up in classes outside of the DateTime namespace? Because we can parse and format things that aren'ts datetimes, like dates, durations, spans, etc. And speaking of brevity...the 0.18 docs for DateTime say that 'time_zone_long_name' is short for $dt-tz-name. I see no evidence of a 'tz' method, though it'd be nice to have around, along with 'tz_name', etc. That should say short for $dt-time_zone-long_name. I'm not that big on brevity, sorry ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: time zone class method? (DT::F::MySQL)
On Wed, 5 Nov 2003, Matt Sisk wrote:
Was there a compelling reason not to have a class method analagous to
DefaultLocale() for timezones, such as DefaultTimezone()?
Nope, no particular reason. But thinking about it, it seems like a bad
idea. Locale is something that I would think the end user always wants to
set for themselves. OTOH, the standard of absent a time zone, we use
floating makes it easy for people to write modules that use DateTime
stuff internally without having to worry about the user have set the
default time zone for their own code.
It strikes me as potentially dangerous action at a distance, because
setting the time zone can impact a _lot_ of calculations, whereas setting
the locale impacts nothing except presentation, which shouldn't be the
concern of CPAN modules using DateTime internally.
DateTimes:
use DateTime;
use DateTime::Format::MySQL;
$F = 'DateTime::Format::MySQL';
$now = DateTime-now(time_zone = 'local');
print now: , $now-datetime, \n;
print tz: , $now-time_zone_long_name, \n;
$mdt = $F-format_datetime($now);
print mdt: $mdt\n;
$now = $F-parse_datetime($mdt);
print now2: , $now-datetime, \n;
print tz2: , $now-time_zone_long_name, \n;
$now-set_time_zone('local');
print now2: , $now-datetime, \n;
print tz2: , $now-time_zone_long_name, \n;
In order to get symmetry, you have to first set_time_zone('UTC') to
convert from 'floating', then set_time_zone('local') to get back to the
original time.
Am I going about this the wrong way?
No, this probably just needs some documentation in DT::F::MySQL about how
to handle the results of parsing.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Mapping an offset to a datetime timezone
On Wed, 5 Nov 2003, Hill, Ronald wrote: I have recently updated the test scripts for the Astro::Sunrise module and would like to incorporate these changes into the DateTime::Event::Sunrise test suite. However, I am unable to map an offset into a datetime timezone. Is there a way to take an offset say -8 hours and look this up and know that this is America/Los_Angeles timezone? No, because there's plenty of timezones for every offset. For example, at -08:00 base offset from UTC we have America/Los_Angeles, America/Juneau, America/Whitehorse, America/Dawson, America/Tijuana, and America/Vancouver. So which one of those corresponds to -8 hours? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: time zone class method? (DT::F::MySQL)
On Wed, 5 Nov 2003, Matt Sisk wrote: And as a convenience, I was suggesting this as equivalent: $dt3 = $dt1-clone(%overrides); If the set() method accepted a time_zone parameter (which is trivial to add), wouldn't this be equivalent to: $dt3 = $dt1-clone-set(%overrides); ?? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: time zone class method? (DT::F::MySQL)
On Thu, 6 Nov 2003, Rick Measham wrote: But the same problem exists ... %parms will contain locale = 'en_AU', so your call to set is now: $dt3-set( locale='en_AU', year=2003 .. second = 27, time_zone = '-1100', locale='latvia' ); So which locale gets used? The second. It's entirely, deterministic, because it's being assigned in order to a hash, so last instance of a key always wins. In fact, that's perfectly valid Perl style, something like: my %params_to_use = ( %defaults, %user_overrides ); -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Class::ClassDecorator
This is the officially blessed way of implementing DateTime.pm decorators. I'll add this to the dev docs sometime soon. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Wrapper code
I finally sat down and wrote this, and it works. The only trick is that authors of module intended to be mixin subclasses of DateTime.pm need to call super::foo instead of SUPER::foo, because I had to implement my own dispatch. The alternative would have been much funkier code that broke the -can and -isa methods. With my code, -can and -isa always work correctly. Except for calls to super::foo, there should be very little overhead for this code, because it uses Perl's native dispatch mechanism for everything else. I'll upload it to CPAN once I have a good name for it. This is currently being discussed on [EMAIL PROTECTED], so feel free to put your $.02 in there. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::TimeZone 0.2504
0.2504 2003-10-25 - If a timezone module cannot be loaded, give a more useful error message if the failure is due to a syntax error in the module, as opposed to the specified time zone not existing. Based on a patch from Alexey Mahotkin. - Require Pod::Man 1.14+, so that head3/head4 markup doesn't cause installation to die. - SuSE puts TIMEZONE=Foo/Bar in the /etc/sysconfig/clock file, but DT::TZ::Local just looked for ZONE= Reported by Pete. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Chinese Calendar Question (fwd)
back to the list, where it belongs ... -- Forwarded message -- Date: Tue, 21 Oct 2003 22:06:45 -0500 (CDT) From: Dave Rolsky [EMAIL PROTECTED] To: Daisuke Maki [EMAIL PROTECTED] Subject: Re: Chinese Calendar Question On Tue, 21 Oct 2003, Daisuke Maki wrote: As you might know I've been working on DateTime::Calendar::Chinese, but right now I'm kind of stuck on the interface, because of two reasons: 1) the Astro stuff. Just where to put it?? 2) The year nocation in CC uses sexagecimal cycles -- I'm not familiar with this -- do Chinese people really use it? Also, I'm fairly sure that Japanese calendars don't use sexagecimal cycles. They usually use 'eras' to distinguish a certain period of time. That also makes inheritance a bit of a problem. I know you've at least thought about implementing a Chinese calendar -- have you thought about this stuff? Do you have any recommendations? Doh, this all should stay on list though. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: deprecate *_rd_as_seconds
On Mon, 20 Oct 2003, Flavio S. Glock wrote: RFC: deprecate DateTime.pm *_rd_as_seconds utc_rd_as_seconds - used internally. DateTime::TimeZone should calculate this value from utc_rd_values(), for compatibility with other calendars. - does not use nanoseconds or leap seconds Not using nanoseconds or leap seconds is quite intentional. Since the calculated values that DT::TZ uses also don't use leap second, it works out fine. local_rd_as_seconds - it looks like it was never used - does not use nanoseconds or leap seconds Is that still in there? Wow. Yeah, that can go. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: please remove me from list
On Mon, 20 Oct 2003, Joshua Hoblitt wrote: On Mon, 20 Oct 2003, Whippo, Ryan K wrote: Please remove me from list Why did you resend this to him? No need to harass him. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: FW: DateTime questions...
On Fri, 17 Oct 2003, Matt Wright wrote:
1) I've installed all of the pre-requisites for DateTime on a RedHat 9 box
and now when I try to perl Makefile.PL for 0.1705 I get:
Testing if you have a C compiler
make: *** No rule to make target `testub'. Stop.
I think this may be some screwiness in the Config.pm included in RedHat 9,
which IIRC is using a version of Perl from the maintenance branch between
5.8.0 5.8.1, because RH is a bunch of morons who like to create annoying
support problems for us upstream authors.
Maybe try something like:
CC=/path/to/gcc perl Makefile.PL
?
Unfortunately, I just realized that the Makefile.PL lies when it says you
can force use of XS with the --xs flag. It actually won't respect that.
Oops.
It also fails to detect a C compiler or pod2man, although right before this
I had just installed all of the pre-reqs for this module which had shown no
errors.
Again, this sounds like a Config.pm problem.
2) I read Dave's article (The Many Dates and Times of Perl) which was very
helpful -- and it seemed like he was concerned with how large the existing
modules got under mod_perl. Do you have any sort of benchmarks or
estimations on how much RAM DateTime DateTime::TimeZone will add to an
app? It seems like having hundreds of modules for the time zone conversions
could add up fast.
Well, if you load _all_ of them it will use up a lot of memory. But my
guess is that in a normal app, if you load them as they're used, you'll
never load more than 5-10 at most.
If you know you're just going to use a small pre-defined set (like just US
time zones), you can preload them at server startup to save memory.
I really don't need a lot of the advanced functionality that DateTime
provides, I basically just want to be able to convert a stored UTC time into
various time zones based on the Olson zones. Am I using the right tool?
Probably.
There's really not much out there for Perl that really supports time zones
in a useful way. In fact, the only other way I know of to do it would be
to set $ENV{TZ} to a new time zone and then call POSIX::tzset(), which
will change what localtime() returns.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Calculate down time
On Mon, 13 Oct 2003, Flavio S. Glock wrote: How about a question for the FAQ? http://perlmonks.org/index.pl?node_id=298788 Calculate down time of devices in prime time (only working hours, excluding p_holidays) by albertc on Oct 13, 2003 at 05:00 GMT+3 I have up down datetime data for devices, I need a function that will provide the downtime within the primetime period. Input will be d_time, u_time, stime (starting time for Primetime, 08:00:00), etime (endtime for PrimeTime, 18:59:59). The function also needs to remove downtime that occured on a public holiday and over weekends! Public holidays will be read from mysql table with Datetime record of each public holiday. Unfortunately, I don't know that we have a great solution yet, do we? I think this could be done with a bunch of spanset intersections, but ideally there'd be business modules to handle a lot of this. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Calendar::Hebrew end-of-day
On Fri, 26 Sep 2003, Flavio S. Glock wrote: Dave Rolsky wrote: On Fri, 26 Sep 2003, Flavio S. Glock wrote: I think this is wrong, because the RD day is an absolute time and should only change at midnight, whatever calendar module you use. year/month/day should change, but RD must stay synchronized with DateTime. Yes. Anything else is broken behavior. We should probably add this to the calendar module dev docs. How should it be phrased? How about: http://datetime.perl.org/developer/calendar.html Converting Between Calendars [...] Rata Die datetimes follow the UTC timescale. Even in calendars in which the day changes at sunset, the RD day still changes at midnight. I added this to the calendar docs. Event Calculations Modules that calculate events should return results using the same class, time zone and locale as the argument: $dt2 = $eclipse-next( $dt1 ); The easiest way to implement this is to calculate a DateTime::Duration, and then return Cargument + duration. Note that if you feed a floating time to a module that makes calculations using UTC, the result will be a floating time that is only valid in the UTC time zone. Most astronomical calculations are in this category, such as sunrise, sunset, and moon position. I made a new document for DateTime::Event modules with this text. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: More flexibly subtract/difference methods
On Fri, 11 Oct 2003, Rick Measham wrote: But some people have indicated that they'd like something a little more flexible. Eugene van der Pijll suggested something like this: my $dur = $dt1-difference( datetime = $dt2, units= [ 'months', 'days' ] ); This would return a duration which only included month and day values, without minutes, seconds, or nanoseconds. $dt1 = 2003-05-15 19:23:33; $dt2 = 2003-04-01 00:00:00; my $dur = $dt1-difference( datetime = $dt2, units= [ 'months', 'days' ] ); So do we now have: 1 month, 15 days or: 1 month, 15 days, 19 hours, 23 minutes, 33 seconds or: 1 month, 15 days, 68400 seconds 1 month, 15 days It seems to me that these 3 cover all the important possibilities, and they have a nice simple API. Looks good to me ... however for _standard_ subtraction I'd like it stored the way I think about it: 2004-04-11 - 2003-04-20 = 1 year, -9 days. I know this breaks some of the internal logic so far as 'if one element is negative, it's a negative duration', but I still think of the difference in terms of the individual units. Hmm, that just seems a little too confusing. It's a lot easier to explain that the difference will always be all negative or positive, and I think it makes it easier to work with. Also, I said this a while back so skip it if you're bored: I'd like a 'normalise' (*normalize = \normalise) function so that: (1 year, -9 days)-normalise(2004-04-11) = (1 year, 11 months, 22 days) and: (45 days)-normalise(2004-04-11) = (1 month, 15 days); (45 days)-normalise(2004-05-11) = (1 month, 14 days); (45 days)-normalise(2003-02-01) = (1 month, 17 days); (45 days)-normalise(2004-02-01) = (1 month, 16 days); This is certainly doable. Instead of converting the duration I'd probably want to return a new one. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: More flexibly subtract/difference methods
On Fri, 10 Oct 2003, Flavio S. Glock wrote: That's true, because you are talking about a DateTime.pm method. (delta_ymd would make sense in other calendars, that don't have exactly 12 months.) However, if DT::Duration is given 'year' units, it should not automatically convert it to months, because I may want to use that information in a non-gregorian context. Well, you might, but you can't ;) Seriously, I think this idea that DateTime::Duration should work for other calendars is bogus, and I've said so before. There's simply too many possible ways for this to break, and while it would be somewhat flexible, it wouldn't be flexible enough to work with many odd calendars (like Discordian, Aztec, etc.). That is, if you move the year/month semantics to the calendar class, then DT::Duration can support (almost) any calendar. No, it can only support some fraction of calendars, those that are lunar, solar, or lunisolar. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: More flexibly subtract/difference methods
On Sat, 11 Oct 2003, Joshua Hoblitt wrote:
DateTime::Duration should focus the Gregorian calendar. There is no
possible way to make it sufficiently generic to support all possible
calendars without giving up functionality useful in it's intended
context. The best we should do to support alternate calendars is to
implement a method that returns an absolute time interval in calendar
independent units.
It did occur to me, however, that we could probably write a duration class
generator really easily. Basically, durations are composed of base units
and derived units. For the Gregorian/UTC system, the base units are
nanoseconds, seconds, minutes, days, and months. The derived units are
hours (minutes * 60) and years (months * 12).
For the Hebrew calendar (which has no leap seconds), the base units are
nanoseconds, seconds, days, months, and years. The derived units are
minutes and hours.
It'd be easy to have something like this:
use DateTime::Duration::Generator
( base = [ qw( nanoseconds seconds minutes days months ) ],
derived = { hours = [ 60 = minutes ],
years = [ 12 = months ],
},
);
The only thing this doesn't handle is the end of month mode stuff. But it
could easily generate the delta_* methods, the various unit methods, and
so on.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime from Rata Die?
On Sat, 11 Oct 2003, Daisuke Maki wrote:
Bah, answering my question...
my $rata_die = DateTime-new(year = 1, month = 1, day = 1);
my $from_rd = $rata_die + DateTime::Duration-new(days = $rd_days);
That works, as does:
{ package DateTime::RataDie;
sub utc_rd_values { @{$_[0]} }
}
my $dt = DateTime-from_object( object = bless [ $rd_days, 0, 0 ],
'DateTime::RataDie' );
This is admittedly a bit sneaky ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: SpanSet Issues and Requests
On Thu, 9 Oct 2003, Flavio S. Glock wrote: DT::SpanSet misses all these methods: next( $dt ) previous( $dt ) current( $dt ) closest( $dt ) as_list Is it ok to implement this in DT::SpanSet? Please do! /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503
On Thu, 9 Oct 2003, Alexey Mahotkin wrote: RM DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm SYNOPSIS + use DateTime; + my $datetime = DateTime-now(); + my $offset = $tz-offset_for_datetime($datetime); RM Rather than this, maybe we need to add a note to all modules RM to signify that $datetime and $dt refer to DateTime.pm RM objects. That's ok, but _something_ should be said about $datetime. I passed time() at first, and was surprised to see the diagnostics. I just noticed that every method's docs says this: Given an object which implements the DateTime.pm API, ... That's pretty clear, I think. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503
On Thu, 9 Oct 2003, Alexey Mahotkin wrote: At the very least I think that the Synopsis must be updated. I agree. I believe that arguments description could be moved after the function description. Current situation is an RPL-ism. Huh? I think the current method descriptions are pretty sensible. Given X, does Y. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
More flexibly subtract/difference methods
So there was some talk about this earlier and I was thinking about how best to make this information available. Currently, the default when subtracting datetimes is to break down the duration into multiple parts, months, days, minutes, seconds, and nanoseconds. From the months piece we can derive years, and from the days piece we can derive weeks. There's also the subtract_datetime_absolute method, which just returns seconds and nanoseconds. I see the primary purpose of this method as returning an object which can be used to repeatedly add or subtract a very specific absolute length duration. But some people have indicated that they'd like something a little more flexible. Eugene van der Pijll suggested something like this: my $dur = $dt1-difference( datetime = $dt2, units= [ 'months', 'days' ] ); This would return a duration which only included month and day values, without minutes, seconds, or nanoseconds. This has some obvious uses, as does requesting only days when you'd rather get back 45 days than 1 month, 14 days. So this makes sense to me. _BUT_ ... Do we really need such a flexible API? For example, will anyone ever want to do this: my $dur = $dt1-difference( datetime = $dt2, units= [ 'months', 'nanoseconds' ] ); My guess is that the answer here is no. So perhaps rather than providing the above API, we should instead offer something like this (taking a page from Date::Calc): # months days my $dur = $dt-delta_md($dt2); # days only my $dur = $dt-delta_days($dt2); # hours, minutes and seconds only my $dur = $dt-delta_hms($dt2); It seems to me that these 3 cover all the important possibilities, and they have a nice simple API. Flavio, you'd mentioned something about wanting to get years back as a unit, but that didn't make much sense to me. Years is _always_ equal to months * 12, so if we have: my $dur = $dt-delta_md($dt2); then $dur-years will give you what you want, right? Anyway, comments on the above API are welcome. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [Fwd: FAIL DateTime-Set-0.1203 i386-freebsd 5.1-current]
On Wed, 8 Oct 2003, Flavio S. Glock wrote: Is this a problem with DateTime::Set Makefile.PL ? This distribution has been tested as part of the cpan-testers [...] PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/perl5/5.6.1/mach -I/usr/local/lib/perl5/5.6.1/BSDPAN -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/00load.# Failed test (t/00load.t at line 8) # Tried to use 'DateTime::Set'. # Error: Can't locate Set/Infinite.pm in @INC (@INC contains: blib/arch blib/lib [...] Looks like a problem with the tester's box, more like it. The Makefile.PL is fine. In general, I find that I don't get much out of these automated reports. The people reporting them often don't respond to me when I ask for more info, and the reports as is are fairly useless. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: ANNOUNCE: DateTime 0.1704
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. I posted a question a few days ago regarding getting the total number of days (or weeks) in a duration. I wasn't sure if $dur-days was working correctly or not. It appears that $dur-days returns the remainder of days in the duration as opposed to the total number of days in the duration. Looking through the source, this appears to be the intention. Is that correct or will 0.1704 now give me the total days? No, the code was broken previously. It should give actual number of days between the two dates. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime 0.1705
Hmm, I don't have much excuse for 0.1704 except that I'd just woken up ;) 0.1705 2003-10-07 [ BUG FIXES ] - Subtracting one datetime from another was still broken, and my fix in 0.1704 broke many other subtractions. Reported by Pierre Denis again. Many thanks to Pierre for paying attention. - Subtracting datetimes where the subtraction crossed a leap second was also broken. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: DT-subtraction bugs in DT::F::Excel and DT::Event::Sunrise
On Tue, 7 Oct 2003, Hill, Ronald wrote: Thanks for that!! I just started looking at the sunrise module to do some updates for preserving the timezone. I just installed the new release of DateTime 0.1704 and all tests now pass for sunrise :) 0.1704 is really broken so try it again with 0.1705 just to make sure ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Locale-register Errors
On Sat, 4 Oct 2003, [NS]Elgyn wrote: Hi everybody, I'm trying to make some custom locales and I've been having trouble getting the register method to work. Even using the example code: DateTime::Locale-register ( id = 'en_GB_RIDAS', en_language = 'English', en_territory = 'United Kingdom', en_variant = 'Ridas Custom Locale', ); gives me: Can't use string (id) as a HASH ref while strict refs in use at /usr/lib/perl5/site_perl/5.8.0/DateTime/Locale.pm line 37. This is a mistake in the docs. Register takes an array of hash references. It'll be fixed in the next release. The documentation also mentions that the id method is required for new custom locales, where abouts is id defined for the default locales? These are all in the DateTime/LocaleCatalog.pm file. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::Locale 0.04
0.04 2003-10-03 - The documentation incorrectly showed the DateTime::Locale-register method as taking an array, rather than an array of hash references. Reported by David Hood. The code is identical to 0.03. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime Problem with nmake test
On Fri, 3 Oct 2003, Michael and Alice Smith wrote: Any ideas as to what the problem is?? # Failed test (t\20infinite.t at line 61) # got: '-2147483648' # expected: '2147483648' # Failed test (t\20infinite.t at line 61) # got: '-2147483646' # expected: '2147483648' # Looks like you failed 2 tests of 39. Failed 1/26 test scripts, 96.15% okay. 2/1494 subtests failed, 99.87% oka NMAKE : fatal error U1077: 'D:\Perl\bin\perl.exe' : return code '0xff' Stop. the infinite stuff has known but as yet unfixed problems on Win32 (and elsewhere) In general, it seems like Perl's handling of IEEE infinite numbers isn't quite up to snuff across all platforms. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone :: dieing on non existing timezone
On Thu, 2 Oct 2003, Mathieu wrote: to my problem i didn't spotted ? If it's the proper way is there any chance it will be included in a future release ? It's definitely not the proper way, but I could be persuaded to add a DateTime::TimeZone-zone_name_is_valid method. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: API for DateTime::Business:Week (was Re: Time Delta)
On Thu, 2 Oct 2003, RIck Measham wrote:
$working_hours = new DateTime::Business::Week(
days = [1 .. 5],
start = {hour = 9, minute = 0},
end = {hour = 17, minute = 30}
);
and, for those with more complex weeks:
$working_hours = new DateTime::Business::Week(
{
days = [3 .. 5],
start = {hour = 9, minute = 0},
end = {hour = 17, minute = 30}
},
{
days = 6,
start = {hour = 9, minute = 0},
end = {hour = 17, minute = 00}
},
{
days = 7,
start = {hour = 10, minute = 30},
end = {hour = 16, minute = 30}
},
);
This all looks reasonable.
Basically Business::Week-new would return an infinite spanset for all
working hours.
Actually, it should probably be something that _contains_ a span set.
It could then be extended to allow for spans so we can include historical
data:
$working_hours-history(
span = $span,
week = $business_week
);
And such things as a finite span:
$working_hours-set_start($dt1); # start of employment
$working_hours-set_end($dt2); # sacked!
In this case I think we might want to create a new object, something like:
my $finite_working_hours =
$working_hours-finite_chunk( start = $dt1, end = $dt2 );
Then we could create other spansets for employee related information
$working_hours-public_holiday( $recurrence ); # or $span or $spanset
I see us needing a couple things:
- Recording the fact that certain days are special non-work days. This
includes both public holidays, company holidays, one shot things like
fumigating the building, etc. We not only want to record when these
are, but their names (Christmas, Company Founder's B-Day, Fumigation
Day, etc.) and possibly other arbitrary data associated with them.
- Partial work days, which could again be a recurrence or a one-shot deal.
These need a name and a start/end time of day.
$working_hours-annual_leave( $span ); # or $spanset
$working_hours-sick_leave( $span ); # or $spanset
This seems like it belongs in a different module.
Then we can set a project for a particular span:
$working_hours-project(
name = 'Project X',
span = $span, # or $spanset
);
If given a 'name' this method returns spanset for that project.
ditto
Now we can get a complete record of activity:
print $working_hours-activity( $datetime );
# Annual Leave
print $working_hours-activity_span( $datetime )-min-ymd;
# 2003-08-12
print $working_hours-activity_span( $datetime )-max-ymd;
# 2003-08-19
ditto again.
And we need a quick boolean test to see if the person was actually at work
print Absent unless $working_hours-at_work;
ditto
Comments/Thoughts/...?
I think you're mixing two sets of functionality.
The first thing we need is a business calendar module that lets us
define standard work days/hours, days off, and partial days.
It should also be able to do calculations like, tell us how many business
days occur between two dates, how many business hours/minutes occur
between two datetimes, and generally let us do business datetime math.
Then we can use that module in another module that implements the
per-employee stuff you're interested in.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Fw: DateTime
On Fri, 3 Oct 2003, James M Snell wrote: But the installation fails when it tries to run the tests: C:\Environment\Perl\bin\perl.exe -MExtUtils::Command::MM -e test_harness(0, 'blib\lib', 'blib\arch') t\00load.t t\01sanity.t t\02last_day.t t\03components.t t\04epoch.t t\05set.t t\06add .t t\07compare.t t\09greg.t t\10subtract.t t\11duration.t t\12week.t t\13strftime.t t\14locale.t t\1 5jd.t t\16truncate.t t\17set_return.t t\18today.t t\19leap_second.t t\20infinite.t t\21bad_params.t t\22from_doy.t t\23storable.t t\24from_object.t t\25add_subtract.t t\26dt_leapsecond_pm.t t\00loadNOK 1# Failed test (t\00load.t at line 6) # Tried to use 'DateTime'. # Error: Can't locate loadable object for module DateTime in @INC (@INC contains: C:\.cpan\buil d\DateTime-0.1703\blib\lib C:\.cpan\build\DateTime-0.1703\blib\arch C:/Environment/Perl/lib C:/Envir onment/Perl/site/lib . C:/Environment/Perl/lib C:/Environment/Perl/site/lib .) at C:\.cpan\build\Dat eTime-0.1703\blib\lib/DateTime.pm line 43 # BEGIN failed--compilation aborted at C:\.cpan\build\DateTime-0.1703\blib\lib/DateTime.pm line 43. # Compilation failed in require at (eval 1) line 2. # Looks like you failed 1 tests of 1. t\00loaddubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay The problem is the Can't locate loadable object for module DateTime. It appears to be an issue with the use of XSLoader but I just haven't been able to track it down. Any ideas on what may be causing this? Is there there actually a compiled DateTime.so? If not, then it's not an XSLoader problem, it's just that nothing is being compiled. If it is, then is it in any of the places that XSLoader is looking for it? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime::Locale 0.04
On Sat, 4 Oct 2003, David Hood wrote: 0.04 2003-10-03 - The documentation incorrectly showed the DateTime::Locale-register method as taking an array, rather than an array of hash references. Reported by David Hood. The documentation is still incorrect, using the example given in the documentation I get: Not an ARRAY reference at /usr/lib/perl5/site_perl/5.8.0/DateTime/Locale.pm line 35. No, this time it's a code bug ;) This seems like a lot of extra work for a single locale, is there a reason why named arguments aren't allowed when registering only one locale? You should able to just pass hashref. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::Locale 0.05
This time I got the bright idea of adding those testy thingies. 0.05 2003-10-03 - Really make the documentation and code match! This time there are even tests for this. Reported by David Hood (again). - DateTime::Locale won't try to load a class if it already has a new() method. This is so you can define multiple locale subclasses in one file and load that file yourself before calling the load() method. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime-Calendar-Hebrew-0.02
On Tue, 30 Sep 2003, Steven J. Weinberger wrote:
If the RD is a value that only changes at midnight (as you noted
previously), then I think my order is right. The way you're suggesting
would change the RD if it's after sunset - wouldn't it? If you took a
DT::Calendar::Hebrew with an incremented RD and converted it to a
DateTime, then converted that DateTime to another DT::Calendar::Hebrew,
wouldn't you keep jumping ahead a day, b/c each time you'd increment RD
b/c it's after sunset on the day in question?
Rata Die, the way we use it in DateTime modules, counts the number of days
since 0001-01-01 00:00:00 UTC, period. That means if you take a DateTime
like 2001-02-23 22:00:00 UTC as a DateTime object, then convert it to a
DT::C::Hebrew object, and then back, it should still represent the same
UTC RD date and time, 2001-02-23 22:00:00.
In this case, I think your code is correct and Flavio is misreading it,
perhaps.
However, I think you do have a bug here:
if($self-{sunset} and $self-{time_zone}) {
my $DT_Event_Sunrise = $self-{sunset};
my $time_zone = $self-{time_zone};
my $DT = DateTime-from_object(object = $self);
$DT-truncate(to = 'day');
my $sunset = $DT_Event_Sunrise-next($DT);
$sunset-set_time_zone($time_zone);
if($sunset $DT) {
$self-{after_sunset} = 1;
@{$self}{qw/year month day/} = _from_rd($self-{rd_days} + 1);
}
}
You truncate the $DT var to the day, then ask for the next sunset after
that $DT. Then you check if $sunset $DT. Well, since you just
truncated $DT and asked for the _next_ sunset, it's _always_ going to be
after $DT!
I think you need to do this:
my $sunset = $DT_Event_Sunrise-next( $DT-clone-truncate( to = 'day' ) );
and not truncate $DT itself.
BTW, if you want to put this code in the perl-date-time repository on SF,
let me know.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: ANNOUNCE: DateTime-Calendar-Hebrew-0.02
On Mon, 29 Sep 2003, Steven J. Weinberger wrote: - merged multiple READMEs into one, according to suggestion from Dave Rolsky Actually, I was suggesting that this text belongs in the module documentation itself. People won't see the README files after installing the module, but this is all important information for those using the module, especially the part about sunset, which directly affects how you use the module. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Re: Olson - Microsoft mappings
On Wed, 24 Sep 2003 [EMAIL PROTECTED] wrote:
This is a bit of a beef I have (as of earlier
today) with the Olson project. I've managed
to auto-map about 174 of the olson zones to
geographic places but am scared I may have to
do the rest by hand. I wish the names were
more along the lines of:
Oceania/Australia/Melbourne-Victoria
Rather than
Australia/Melbourne
Once I've completed my research we should have:
$time_zone{$continent}{$country}{$region} and/or
$time_zone{$continent}{$country}{$city}
You do realize that mapping time zones to countries will take a _lot_ of
maintenance, right?
Countries are changing all the time. Think back to the end of the cold
war, when the USSR dissolved, along with Yugoslavio and Czechoslovakia,
and at the same time E W Germany became a single country.
And how do you handle things like Taiwan Hong Kong? Are they separate
countries? Hong Kong was once sort of a separate country, but is now
clearly part of China. Is Taiwan part of China? Depends who you ask ;)
My wife is Taiwanese and I sure as hell think they're separate countries,
but ask many mainlanders and you'll get a different answer.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Event::Sunset problems
On Wed, 24 Sep 2003, Flavio S. Glock wrote: Steven J. Weinberger wrote: I'm trying to use DateTime::Event::Sunset in my DateTime::Calendar::Hebrew module, but I'm having a problem. Below is my test code. The results from the code are: 2003-09-24T10:42:00 2003-09-24T22:48:00 Sunrise wasn't at 10:42 and the sun will set well before 22:48. Is there something I'm doing wrong? I think these results are in UTC time. Hmm, this should probably be changed so that the returned object has the same time_zone as was passed to next(). I think this change would go in DT::E::Sunrise. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Event::Sunset problems
On Wed, 24 Sep 2003, Flavio S. Glock wrote: This is what it looks like (tested!): --- #!/usr/local/bin/perl use DateTime; use DateTime::Set 0.1202; use DateTime::Event::Sunrise; my $dt = DateTime-new( year = 2003, month = 9, day= 24, time_zone = 'America/New_York', ); my $sunrise = DateTime::Event::Sunrise-sunrise ( longitude ='-73.59', latitude ='40.38', altitude = '-0.833', iteration = '1' )-set_time_zone( 'America/New_York' ); I really don't think we should make users do this if we can avoid. my $rise = $sunrise-next($dt); print $rise-datetime, , $rise-time_zone_long_name, \n; This should probably set the returned datetime to the same timezone as the given datetime. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: figuring out the number of sundays in a given year
On Wed, 17 Sep 2003, Ron Hill wrote: Ok, I see I can just do my $dow = $dt2-day_of_week( year = $dt-year, ); The day_of_week() method DOES NOT TAKE ARGUMENTS! I don't know what you think the code above does, but I can tell you that all it does is return the day of the week for the $dt2 objcet, and ignores everything else. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: figuring out the number of sundays in a given year
On Fri, 19 Sep 2003, Joshua Hoblitt wrote: The day_of_week() method DOES NOT TAKE ARGUMENTS! I wonder if it's worth the overhead of checking for extraneous parameters on all methods? I'd rather try to keep accessors as quick as possible. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Some examples for the FAQ
On Sat, 13 Sep 2003 [EMAIL PROTECTED] wrote: For example, the Wednesday of the current week is: my $today = DateTime-today; my $wednesday = $today - ( $today-day_of_week - 3 ); How about adding a 'week' parameter to the 'truncate' method: print DateTime-today -truncate( to = 'week' ) -add( days = 2 )-ymd; An excellent idea, especially since I just realized I need this for something else I'm working on ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime 0.1702
0.1702 2003-09-18 - Added truncate( to = 'week' ). Suggested by Flavio Glock. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: figuring out the number of sundays in a given year
On Wed, 17 Sep 2003, Hill, Ronald wrote: I checked the docs for datetime and used them F:\scriptsperldoc DateTime|grep day_of_week File STDIN: $dow= $dt-day_of_week; # 1-7 (Monday is 1) - also dow, wday _0. So for example, this class provides both day_of_week() and day_of_week_0() methods. treats Monday as the first day of the * day_of_week, wday, dow Am I missing something? Josh is confused because you're passing arguments to the day_of_week method. These arguments are completely ignored by DateTime.pm! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT 0.17 test failure on 5.8.1 RC4
On Sat, 13 Sep 2003, Joshua Hoblitt wrote: t/03components..Invalid offset: -124 # Looks like you planned 122 tests but only ran 55. # Looks like your test died just after 55. t/03components..dubious Test returned status 255 (wstat 65280, 0xff00) Scalar found where operator expected at (eval 153) line 1, near 'int' $__val (Missing operator before $__val?) Operator or semicolon missing before typedef at (eval 156) line 1. Ambiguous use of resolved as operator at (eval 156) line 1. DIED. FAILED tests 56-122 Failed 67/122 tests, 45.08% okay The fault here is the test. It was passing a bad offset as a time_zone parameter to DateTime-new. I'll release a new version. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime 0.1701
0.1701 2003-09-15 [ BUG FIXES ] - If from_epoch was given a fractional epoch with a floating point value with more than 9 digits after the decimal point, the object ended up containing a floating point number of nanoseconds. We now truncate this number to an integer. Fixed by Joshua Hoblitt. - The %V strftime specifier was documented, but not implemented. Reported by Joshua Hoblitt. - Test #56 in 03components.t would die with Invalid offset: -124 when run with DateTime::TimeZone 0.2502+. Next time, I'll read my own docs ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Defeating DateTime::new hour limitation
On Fri, 12 Sep 2003, Claus Färber wrote: Dave Rolsky schrieb: But there are only 24 hours in a day. What should DateTime do with hour = 24? It should be the beginning of the next day, of course (i.e. 00.00 on the next day). As ISO 8601 defines T2400, people might expect that behaviour. Then it can be handled in the DT::F::ISO8601. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::Fiscal::Year Interface change
On Thu, 11 Sep 2003, Jesse Shy wrote: let me make sure I have this correct. Under the proposed way all the methods will take at least 1 argument -- a dt object that is the target date -- and the routine will run completely on each call? No problem. Right. If we wanted to optimize this later we could use memoization, but for now a good API and correct results are fine. Speed can come later. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Problem with DateTime::Format::DateManip v0.01
On Fri, 5 Sep 2003, David Wheeler wrote:
Can you do another test for me (since I don't have a platform that
needs tzset)? Can you tell me how it affects use of local? Here's a
test script:
#!/usr/bin/perl -w
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?
Yep, you need to call it again. Whatever tzset does is something at a C
library level, not a Perl level, so the localization doesn't do anything.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Problem with DateTime::Format::DateManip v0.01
On Fri, 5 Sep 2003, David Wheeler wrote:
Bah. Thanks for that. Does this work?
#!/usr/bin/perl -w
use strict;
use POSIX qw(tzset);
print scalar localtime, $/;
{
local $ENV{TZ} = Asia/Tokyo;
tzset;
print scalar localtime, $/;
}
tzset;
print scalar localtime, $/;
yup
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Set - Number of elements in set
On Tue, 3 Sep 2003, Rick Measham wrote:
ALSO If we go this path or not, I'd prefer not to get plain undef back.
I'd like an indication that it was 'too hard to count', or that it was
'over 10,000'.
But undef means unknown, and if we can't count, we don't know how many
elements are in the set. We certainly can't return a number, and we can't
return a string or object because then people will do:
if ( my $count = $set-count ) { ... }
and that would succeed. So that leaves undef or an exception. It seems
silly to throw an exception here, and in fact I really don't like the idea
of accessor methods throwing exceptions.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
ANNOUNCE: DateTime::Format::ICal 0.08
0.08 2003-09-04 - Negative durations were formatted as positive with Perl 5.00503. Fixed by Flavio Glock. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Problem with DateTime::Format::DateManip v0.01
On Thu, 4 Sep 2003, Jonathan Leffler wrote: I don't know if it is significant that I'm running in US/Pacific time zone, which is 3 hours adrift from US/Eastern - it doesn't seem to be that simple as running with TZ=US/Eastern does not alter the answers. It's probably that simple. Simply setting the TZ env var probably won't do much. An app has to call POSIX::tzset() for that take effect. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Problem with DateTime::Format::DateManip v0.01
On Thu, 4 Sep 2003, Dave Rolsky wrote: On Thu, 4 Sep 2003, Jonathan Leffler wrote: I don't know if it is significant that I'm running in US/Pacific time zone, which is 3 hours adrift from US/Eastern - it doesn't seem to be that simple as running with TZ=US/Eastern does not alter the answers. It's probably that simple. Simply setting the TZ env var probably won't do much. An app has to call POSIX::tzset() for that take effect. I take it back. The real problem is that Date::Manip doesn't parse time zone offsets when given an ical format datetime. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DT::Format::ICal 0.07
0.07 2003-09-02 - Added format_recurrence() docs. Implemented by Flavio Glock. - Require DateTime::Event::Recurrence 0.03 to get hints on formatting unbounded recurrences. - Updated to work with newer versions of DateTime.pm and DateTime::Span. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set - Number of elements in set
On Tue, 2 Sep 2003, Flavio S. Glock wrote: If we want to document and specify that this is an error, then the size should be infinite. Otherwise, if we might want to allow this in the future, undef is correct. I don't feel too terribly strongly either way. Ok. So let's document that it is an error. Sounds good. We can always change it later if we decide we need that flexibility. How about: return 'infinity' when we _know_ the set is infinite, and return 'undef' when we don't know how big the set is. That works. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [Patch] DT::TZ Offsets
On Fri, 22 Aug 2003, Joshua Hoblitt wrote: I didn't look up the offset for Kiribati, actually, so thanks for the correction. I think the republic crosses at least 4 timezones. Offsets of more than 12 hours aren't that strange; countries near the international date line can choose on which side of that line they are. I wouldn't be surprised if some parts of Alaska have been about +1530 at some point. Offsets of 24 hours are something else entirely, of course. True, but that's not a reason to go out of our way not to support them. Ok, I'm convinced. Just go ahead and check it in as implemented. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [cpan #3303] test t20infinite.t failed on Linux mandrake 9.0
[ moved onto the datetime list ] On Thu, 21 Aug 2003, Guest via RT wrote: This message about DateTime was sent to you by guest via rt.cpan.org Full context and any attached attachments can be found at: URL: https://rt.cpan.org/Ticket/Display.html?id=3303 The test t/infinite20.t (DateTime-1601 with perl 5.8.0) failed at line 53 and then at line 61 (certainly because of the first failure). I added a debug line after line 53: print STDERR \nlong_ago=,$long_ago-ymd,\nneg_dur=,$neg_dur-deltas,\nneg2=,$neg2-ymd,\nneg=,$neg-ymd,\n\n; and I get the following output: t/20infiniteok 8/40 long_ago=-10-01-01 neg_dur=months0days-infminutes0secondsnannanoseconds-inf neg2=-0001--01--01 neg=-2147483648--2147483648--2147483648 There is certainly a misinterpretation of -infinite time, is negative enough or should it be -inf--inf--inf ? It should ben -inf for all values. Can you respond with the output of perl -V? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [Patch] DT::TZ Offsets
On Fri, 22 Aug 2003, Joshua Hoblitt wrote: Can you change it so that the maximum offset is 24:00:00 and then check it in? There's no official limit on offsets are there? I can envision some small country declaring an offset of greater then 24hours. You can? That doesn't make much sense to me. If it happens, we can change the code ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Subtraction Broken?
On Sat, 23 Aug 2003, Eugene van der Pijll wrote: The only problem is that DT::subtract_datetime doesn't use it. It probably should. (It would be even better if there was an option to calculate the difference in days secs. But the default should probably be to return a difference of months, days, minutes, seconds.) I think the default should probably be the accurate method, but I do think offering a way to return the other values would be good. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set - Number of elements in set
On Tue, 19 Aug 2003, Flavio S. Glock wrote: There are some cases when we don't know if a recurrence has any event at all. This may happen when you do an intersection of recurrences. Otherwise, if they don't have a start and end, they are infinite, right? But 'undef' is ok - I'll change that. Well, the set may not have a start or end, but it's quite possible that the callback may simply not return anything before or after certain datetimes. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug with $dt-substract ??
On Fri, 15 Aug 2003, Thomas Klausner wrote: I'm getting strange results when subtracting dates from one another: I make a new $dt object, setting the date to e.g. 2003-05-31. If I subtract one month, I do not get 2003-04-30, but 2005-05-01, which seems wrong to me. This problem only occurs in months with 31 days, exept August, which works. March gives even stranger results. I attached a small script illustrating the problem. It's either a bug (if it is I could try to track it down more closely), or I'm doing something dumb (in which case I'd appreciate some advice...) I'm using DateTime-0.1601 and perl.5.8.0 The results are actually consistent with the internal logic, but definitely surprising for end users. If you add end_of_month = 'preserve' it does what you are wanting. I wonder if we shouldn't make preserve the default EOM mode when the duration is negative? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::Wrapper API/semantics
On Fri, 8 Aug 2003, Flavio S. Glock wrote: Dave Rolsky wrote: Anyway, does this API sound sane? And if it does, anyone have any really clever implementation ideas? I have some scary ones involved AUTOLOAD and constructing classes on the fly. help me understand it - Does something like DT::Incomplete could be a wrapping class? No, this is so that we can mix and match additional behaviors that would otherwise be done as subclasses. Joshua's caching class is one obvious example. Another might a class that didn't die on invalid params, but converted them to something valid. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime 0.1601
0.1601 2003-08-07 [ BUG FIXES ] - On platforms like Win32, where we can't find a finite() or isfinite() function/macro, the DateTime::LeapSecond code wasn't being loaded, so many tests failed. Reported by Ron Hill. Thanks, Ron. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::TimeZone::LMT
On Thu, 14 Aug 2003, Sam Vilain wrote: A good point. This is needed so that when we serialize DateTime objects, we don't need to serialize the timezone object too. A good point - are you providing these methods for some of those `other' :) persistence tools ? Storable: $dt-STORABLE_freeze $dt-STORABLE_thaw This exists. Pixie: DateTime::px_is_storable $dt-px_freeze $dt-px_thaw This doesn't, but could probably share the same code as the Storable hooks. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: leap seconds in XS
On Wed, 6 Aug 2003, Dave Rolsky wrote: I just checked this in, but I'm not sure if it's much faster. It'd be good if someone who knows more about about C could look at the implementation and see if there's anything they can think of to improve it. Also, I should probably change the generated code to use the binary search method that Flavio's DateTime::LeapSecond generated code uses. Ok, I did some benchmarks and it looks like date math involving leap seconds (basically an DateTime object where the time zone is _not_ floating) has sped up about 10% or so, which is definitely a good thing. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::TimeZone::LMT
On Mon, 12 Aug 2003, Rick Measham wrote: Attached is the above module. Unless there's strenuous objections I'll CPAN it. I just wish for this and for ::Alias that we could hook in better without messing with the internals. While I'm thinking of it, I'd like to be able to set names and short-names for offsets. I have a list of short names in Strptime, but I've love to be able to get these back from TimeZone somehow. Just like we do with Olsen (or is it Olson, one's the twins, one's the time, can't ever remember which!). I like the idea, but the longitude needs to be settable per object, not just for the whole class. Otherwise two modules couldn't both use this one! This also makes the whole name thing moot, since the object would always return LMT for the name. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC: DateTime::TimeZone::LMT
On Tue, 12 Aug 2003, Claus Färber wrote: Rick Measham [EMAIL PROTECTED] schrieb/wrote: While I'm thinking of it, I'd like to be able to set names and short-names for offsets. For short names, that might be a good idea. But for long names, it would break this: | name | Returns the name of the time zone. If this value is passed to the | new() method, it is guaranteed to create the same object. A good point. This is needed so that when we serialize DateTime objects, we don't need to serialize the timezone object too. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime-localtime() (was Re: DT::TZ test failure)
On Sun, 10 Aug 2003, John Siracusa 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. ...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 'local' won't always work ;) I'd be more likely to call it with an explicit time zone than with 'local'. Here's example of what I expect to be common usage. Let's say someone want the default date range in the text fields on a web form to be the past 30 hours. Joe Perl Programmer is going to glance at the DT docs and then write: $start = DateTime-now-subtract(hours = 30)-strftime(...); $end = DateTime-now-strftime(...); Joe Perl Programmer is going to be very surprised, IMO, and the fix is not to add warnings to the docs... ;) Like I said, I think there are very good reasons not to default to local, especially since that it won't necessarily work at all. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Re: [rfc] HiRes
On Sat, 9 Aug 2003, Joshua Hoblitt wrote: On the one hand, I agree. HiRes is bad, and hires is a bit worse. OTOH, _so_ many people are already familiar with Time::HiRes, that having our own variation on it may be confusing to as many people, or more, as hires is. So are we back to DT::HiRes? Or just rename the constructor? I would like to see this functionality make it into the next release. I guess sticking it in a separate module DateTime::HiRes works, since that way we don't force people to load Time::HiRes if they don't need it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::TZ test failure
On Sat, 9 Aug 2003, Joshua Hoblitt wrote:
I'm getting this failure from the CPAN dist and when I parse the Olson files myself.
Since 0.25 installed for me without errors at some point in the past I'm assuming
that this failure is being caused by a recent release of DT. Can anyone reproduce
this?
# This is to check a bug in DT::TZ::_span_for_datetime, where it
# was always looking at the LOCAL_END of the current max_span.
#
# Australia/Sydney's max_span (before generation) has a LOCAL_END
# of 63518522400 and UTC_END of 63518486400. The values above
# create a utc_rd_seconds value that is after the UTC_END but
# before the LOCAL_END.
my $dt = DateTime-from_object( object = TestHack-new );
eval { $dt-set_time_zone( 'Australia/Sydney' ) };
ok( ! $@, 'should be able to set time zone' );
161 ok( $dt-is_dst, 'is_dst should be true' );
DateTime.pm now sets the time zone to floating when it creates an object
in the from_object() method. I think it used to be UTC. I'll release a
new DT::TZ to handle this.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DT::Wrapper API/semantics
On Fri, 9 Aug 2003, Rick Measham wrote: On Sat, 2003-08-09 at 06:55, Dave Rolsky wrote: So what I think we really want is this: my $Wrapper = DT::Wrapper-wrapper( [$class1, $class2, $class3] ); Maybe my approach has some holes, but have a look at the attached and see what you think ... The big hole is that you set @ISA when you create the decorator, but what if someone creates two _different_ decorators? In that case you've just broken the first one you made. Also, we want to be able to use SUPER::foo inside the decorating classes. For example, Josh's DT::Cache will obviously need to call it's parent's new() method. This means that we can't just use multiple inheritance, but instead we need to create an actual chain of inheritance. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime::Locale 0.04
0.03 2003-08-06 - Once a locale is loaded, it is cached in memory, so that locale objects are singletons. Calling methods that change the locale registry, like register() or remove_alias(), clear that cache. This should provide a noticeable speed boost when constructing many DateTime objects with the same locale. Based on a patch from John Siracusa. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: leap seconds in XS
On Wed, 6 Aug 2003, Joshua Hoblitt wrote: How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ? Seems like a good idea. Do you want to do it or should I? I'd like to keep it separated. I believe it maybe useful outside the context of DT. I suspect updates to it will be quite infrequent, though. Other than new leap seconds, why else would it change? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: leap seconds in XS
On Wed, 6 Aug 2003, Flavio S. Glock wrote: Dave Rolsky wrote: Ok, I did some benchmarks and it looks like date math involving leap seconds (basically an DateTime object where the time zone is _not_ floating) has sped up about 10% or so, which is definitely a good thing. How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ? Seems like a good idea. Do you want to do it or should I? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime Performance
On Sun, 3 Aug 2003, John Siracusa wrote:
CGI-new(''): 5 wallclock secs @ 1869.16/s
(5.25 usr + 0.10 sys = 5.35 CPU)
CGI's constructor really doesn't do much at all, especially if there's no
query string or form submission to handle.
Date::Simple-new('2003-01-01'): 2 wallclock secs @ 4273.50/s
(2.31 usr + 0.03 sys = 2.34 CPU)
This also doesn't really do much of anything.
# ... 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 seconds, etc.
DateTime-now(): 21 wallclock secs @ 547.95/s
(18.13 usr + 0.12 sys = 18.25 CPU)
Ditto.
DateTime does well against Date::Manip, but not so well against even a
big module like CGI. But for object creation alone, should it really
be ~5x as slow as Date::Simple?
Yeah, probably.
Total Elapsed Time = 19.91729 Seconds
User+System Time = 14.60729 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
27.6 4.035 4.685 20274 0.0002 0.0002 Params::Validate::_validate
24.0 3.510 17.549 1 0.0004 0.0018 DateTime::new
18.9 2.770 3.809 10001 0.0003 0.0004
DateTime::Locale::_load_class_from_id
This seems quite odd. It really doesn't do much.
8.96 1.309 2.647 10020 0.0001 0.0003 DateTime::TimeZone::BEGIN
And this is completely mystifying. Can you show us your code?
These numbers confuse me a bit, because I'm only creating about 30
Widget objects in my mod_perl request, not 10,000. But I see a very
significant speed hit, even if I replace my entire Widget-new() call
with a simple call to DateTime-new(). Maybe it's some sort of
mod_perl/DateTime interaction?
No, DateTime just does a lot of stuff.
Anyway, I don't want to get sidetracked into mod_perl stuff. I'm not
sure what (else) to make of the results above, other than a possible
wish that I could turn off Params::Validate's validation in certain
performance-critical situations.
You can turn it off for everything by setting the PERL_NO_VALIDATION
environment variable to true. There's no way to turn it off and on at
runtime currently, though this could be added.
So, what does everyone else think of the object creation performance
situation? Is it simply good enough to be 3x faster that
Date::Manip::ParseDate()? Are there any obvious areas that I should
consider before I start mucking around with DateTime::new()?
Considering that up til now my concern has been primarily on getting
things correct, I wouldn't worry about it. There are definitely some big
performance improvements possible. One possibility is to move the leap
second bits into the DateTime XS code, which should help a lot. The
timezone stuff can also benefit from being rewritten as XS, but that won't
help the particular cases you benchmarked, since the UTC and floating time
zones are quite fast already.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote: $dt = DateTime-now_high_res(); or $dt = DateTime-now( high_res=1 ); Thats a possibility too. Although to me that syntax would seem to guarantee HiRes support to be available. I don't know if we want add Time::HiRes as a dependency. In general, I have no qualms about dependencies if they're on known-to-be-good modules _and_ they provide some useful functionality. In this case, it's even less of a concern since Time::HiRes is a core module. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Claus Färber wrote: Joshua Hoblitt [EMAIL PROTECTED] schrieb/wrote: OTOH, maybe I dont understand how your DateTime-hires( 1 ) call would work without adding HiRes as a dependency. It does - ... IMO no DateTime::* module should depend on Time or Date modules outside of that namespace. DT should replace them eventually. Maybe DateTime::Hires as a replacement for Time::HiRes? Um, what would it do differently? Are you really proposing to implement the same functionality as Time::HiRes in a new namespace? That just seems silly. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
In general, I have no qualms about dependencies if they're on
known-to-be-good modules _and_ they provide some useful functionality. In
this case, it's even less of a concern since Time::HiRes is a core module.
We can't import Time::HiRes's time as there is already a DateTime::time()
That's alright. I'm not that big on importing stuff.
Index: lib/DateTime.pm
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
retrieving revision 1.232
diff -u -r1.232 DateTime.pm
--- lib/DateTime.pm 31 Jul 2003 23:49:41 - 1.232
+++ lib/DateTime.pm 2 Aug 2003 21:40:36 -
@@ -48,6 +48,7 @@
use DateTime::LeapSecond;
use Params::Validate qw( validate SCALAR BOOLEAN HASHREF OBJECT );
use Time::Local ();
+use Time::HiRes;
# for some reason, overloading doesn't work unless fallback is listed
# early.
@@ -385,7 +386,7 @@
# Because epoch may come from Time::HiRes
my $fraction = $p{epoch} - int( $p{epoch} );
-$args{nanosecond} = $fraction * MAX_NANOSECONDS
+$args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
if $fraction;
What's this for? I think it was working as is.
# Note, for very large negative values this may give a blatantly
@@ -403,7 +404,7 @@
}
# use scalar time in case someone's loaded Time::Piece
-sub now { shift-from_epoch( epoch = (scalar time), @_ ) }
+sub now { shift-from_epoch( epoch = Time::HiRes::time, @_ ) }
Yep, looks right
I'm not sure exactly how to test this. Call now times several times in
a row and make that one of the results is non-zero for nanoseconds?
Yeah, I don't know a good solid way to test this either. Maybe override
Time::HiRes::time() in the test?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Dave Rolsky wrote:
# use scalar time in case someone's loaded Time::Piece
-sub now { shift-from_epoch( epoch = (scalar time), @_ ) }
+sub now { shift-from_epoch( epoch = Time::HiRes::time, @_ ) }
Yep, looks right
I take it back. I thought we'd have now() and hires_now(). I think
having nanosecond at 0 makes sense to most people.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote: I take it back. I thought we'd have now() and hires_now(). I think having nanosecond at 0 makes sense to most people. We have an awful lot of constructors already. Maybe we should put this into another package? The more I think about this the more I like it. We'll only have to commit the fractional seconds fix to DateTime.pm. I'd suggest DateTime::HiRes.pm to be included with the DT distribution. The down side is this functionality wouldn't be available to decorators unless DateTime::HiRes was a subclass of DT. What would DateTime::HiRes offer besides a hires_now() method? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DT::F::Bork
On Fri, 1 Aug 2003, Joshua Hoblitt wrote: [1] Why UTC? Wouldn't Europe/Stockholm be more appropriate? I committed this change to CVS but I think it may have uncovered some sort of weird bug in DT::TZ. Could you run the tests from the CVS version and let me know if they hang? It's not hanging, it's just _really_ slow. I'll look into it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DT::F::Bork
On Fri, 1 Aug 2003, Joshua Hoblitt wrote: [1] Why UTC? Wouldn't Europe/Stockholm be more appropriate? I committed this change to CVS but I think it may have uncovered some sort of weird bug in DT::TZ. Could you run the tests from the CVS version and let me know if they hang? I take it back, there's no bug. It's just that it has to generate _all_ the time zone changes up to the year !! That's going to take a while. I'd recommend using a year a little closer to our own. DT::TZ ships with the changes pre-generated 30 years out, so dates in that range are quick. Dates within a couple hundred years out aren't too bad either, but thousands of years ahead will be slow. I should probably document this somewhere more obvious. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Bug in DT::F::Bork
On Fri, 1 Aug 2003, Claus Färber wrote: Dave Rolsky [EMAIL PROTECTED] schrieb/wrote: That's going to take a while. I'd recommend using a year a little closer to our own. DT::TZ ships with the changes pre-generated 30 years out, so dates in that range are quick. Why does DT::TZ work that way? It should be possible to determine whether a date is DST without generating data for all the years inbetween. Because this was relatively easy to implement. It uses more or less the same code as is used to generate the initial data set. (The problem is, of course, that it will need year, month, and time information for that and so probably must create a DT object w/ UTC timezone ... or use DateTime::_rd2ymd) Well, it does that anyway. Basically it comes down to this being quite a bit easier than a sparse implementation. A sparse implementation would be more complex, especially since I'm afraid that someday we'll see a time zone with 2 changes per year (you never know). If someone else wants to work on a patch, I'd be happy to accept it ;) However, what I'd really like to do is rewrite all of this in XS, at which point it might not make much difference. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime 0.1501
On Wed, 30 Jul 2003, Joshua Hoblitt wrote: But why would people do that on Solaris is my question. For some reason it doesn't always identify that gcc is available (thats how I noticed the problem). Don't ask me why someone would install the XS version then switch to pure-perl. Never the less it still shouldn't do that. It looks like the problem is with Dynaloader. No, Dynloader's doing what it's supposed to, which is try to find an .so for the module. The problem is that the one it finds is for the wrong version. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::Infinite bug: adding years
On Fri, 1 Aug 2003, Eugene van der Pijll wrote: I've encountered a bug in DT::Infinite math. It seems that adding a number of days to DT::Infinite::Future results in a DT::I::Future object again, but adding a number of years changes it. For example: my $dt = DateTime-now; my $dt_inf = DateTime::Infinite::Future-new; print $dt_inf$dt ? 'OK' : 'NOK', ' ', $dt_inf-year; $dt_inf-add( days = 20 ); print $dt_inf$dt ? 'OK' : 'NOK', ' ', $dt_inf-year; $dt_inf-add( years = 20 ); print $dt_inf$dt ? 'OK' : 'NOK', ' ', $dt_inf-year; Output: OK inf OK inf NOK -793 I presume that this is because the code for adding days is much simpler than the code for adding months. I don't know how best to fix this; perhaps a separate DT::Infinite::add_duration method? Fixed with one line in DateTime.pm-add_duration ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: DateTime 0.1503
0.1503 2003-07-31 [ BUG FIXES ] - Adding a duration with delta months to an infinite DateTime was quite broken. Reported by Eugene van der Pijll. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime 0.1501
On Wed, 30 Jul 2003, Joshua Hoblitt wrote: - For this release, at least, the module always uses Dynaloader. This is in order to see if this fixes a problem on Solaris where the install library version of the DateTime .so file is loaded instead of the newly compiled version in the blib directory. bash-2.03# perl Makefile.PL --pm Why'd you do that? You told it to _not_ compile the XS version. t/00load# Failed test (t/00load.t at line 6) # Tried to use 'DateTime'. # Error: DateTime object version 0.15 does not match bootstrap parameter 0.1501 at /usr/local/lib/perl5/5.8.0/sun4-solaris-thread-multi/DynaLoader.pm line 249. # BEGIN failed--compilation aborted at /root/.cpan/build/DateTime-0.1501/blib/lib/DateTime.pm line 38. # Compilation failed in require at (eval 1) line 2. t/00loadNOK 1# Looks like you failed 1 tests of 1. But it shouldn't blow up like that. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
