Data::ICal
Dave, I just noticed Data::ICal out on the CPAN and was wondering if you'd taken a look at it. It seems fairly comprehensive on parsing and generating ICal data. Perhaps it's worth keeping an eye on for potential use in the various ICal datetime modules (though if it ain't broke, don't fix it probably applies in this case). Internally it appears to use Date::ICal ... I was more interested in the parsing. So I'm not suggesting changes, only soliciting your opinion on the suite. http://search.cpan.org/~jesse/Data-ICal-0.04/ Cheers, Matt
Re: DateTime.pm 0.30 coming up real soon now
Dave Rolsky wrote: I will make a list of all the problems I've run across so far, along with examples that demonstrate them. Anyone who can come up with a solution that handles all of these problems is a far smarter person than I am ;) It might already be out there...but can you wikifi it as well, please? I've been involved/lurking for quite a while now and though I could produce a few of these entries I still cannot rattle them off from memory. And for the list...perl makes the easy things easy and the hard things possible, as the saying goes...date math is easy. Absolute time is easy. Dates with times is hard, but so is visual cognition. :) Matt
Re: Store DateTime::Event::Cron objects ?
Hello Kaare, I'm using the nice DateTime::Event::Cron module. I do want to save the cron schedules in a database. The easiest way would be to stringify and destringify the objects. Is this possible? Since, in essence, DT::E::Cron is designed to convert cron strings into datetime recurrences, why not use the original cron specification as the string to be stored? The original() method will return the string used to construct the object. Matt
Re: Store DateTime::Event::Cron objects ?
Quoting Kaare Rasmussen [EMAIL PROTECTED]: The same question goes for DateTime::Set objects. Can they be made persistent? Flavio was working on something along these lines, though I'm not sure of the current status. Check out the following thread: http://marc.theaimsgroup.com/?l=perl-datetimem=111524990432703w=2 Matt
Re: Data::Juxtapose 0.01 [Re: patch: DateTime::TimeZone PP redundant structures]
The basic format seems good. I'm not sure about using weak_ref, though -- what if an object or structure falls out of scope, yet there's still a key in the data registry? If another ref comes along whose fingerprint matches that key, does it end up getting replaced with undef ? (I'm kind of sleepy at the moment, so I could be misreading the code). Also, as originally implemented in the context of DateTime::TimeZone, I was using class structures and class methods. You've moved it into object mode, which is fine, but I'm curious as to how you utilize the shared object. I'm assuming it's a single object in the DT::TZ base class? Cheers, Matt
Re: patch: DateTime::TimeZone PP redundant structures
Daisuke Maki wrote: I like this... but I'd like to generalize this juxtapose thing into a separate package and release it, if it's okay with you guys (especially Matt)? That's fine with me. How about Data::Juxtapose ? You'd probably want to design it so that you can plug in different fingerprinting methods (as opposed to limiting it to md5_hex(Dumper()) ). Matt
Re: DateTime::TimeZone in XS is ready in CVS
Quoting Dave Rolsky [EMAIL PROTECTED]: If this could be integrated with using C data structures that'd be pretty cool. I have the code somewhere if you can't find it. I'll take a look when I find some time. I've been looking for an excuse to mess with XS anyway. As I recall, most of the work was on the front end, in the script that parses the Olson data. Matt
Re: DateTime::TimeZone in XS is ready in CVS
At some point a while back, I analyzed the data structures used in forming the timezone objects and found that there was a lot of redundant structures, particularly in cases where you were loading a large number of zones. I hacked the data structure to re-use common references whenever possible and this made a significant difference in the total size used when many timezone objects were loaded, but not much (in fact none) when only a single zone was used. I'll see if I can find my work. I was using Data::Dumper for the trickery, but I'm sure it could be switched over to Storable. I have no idea regarding the specific problem with the XS apparently using more memory. Matt
Re: Storing recurrences in a SQL DBMS?
Dave Rolsky wrote: - Allow only a fairly limited set of recurrences, store them as iCal strings, and query based on string contents. This limits the flexibility of the system, but is potentially quite efficient. This is what I've done in the past. The iCal string is only the recurrence part. I stored my boundary dates in separate columns. It worked quite well for me -- however, I was developing the back-end for the application, which was all Perl. There was also a front-end for the application that was written in PHP -- in this case the PHP developer had to write some routines to *generate* those iCal recurrence strings based on a form. Let me know if you'd like more details -- it's pretty straight forward. Matt
Re: DateTime::Event::Cron and limiting infinite sets
Hi Sam. I've cc'd the datetime mailing list so that they can chime in if they want. I am trying to write a converter for crontab entries into another format (iCal). Unfortunately I need a limited recurrence set as the output module does not allow infinite sets. I thought that using the %parms or the %set_parms I would be able to limit the Set produced using from_cron and then pass that on as a finite DateTime::Set to the other module. Should the approach I am taking (to limit the resulting Set using a span) work? When searching on Google I found very limited results for use of the DateTime::Event::Cron module and so I wonder if you could point me in a direction for reference information. Do you have any other suggestions or ideas? It sounds to me like you're trying to translate one grammar (cron) into another (ICal). Alternatively, if you can get the constraints expressed as recurrences and sets, then you need an ICal generator that will produce the results you want. Currently, DateTime::Event::Cron is not using the DateTime::Set logic internally to produce its results (I did this for speed at one point and keep meaning to run some benchmarks with the more recent datetime code to see how it compares...but...time and all). Short of converting directly from cron grammar to ICal grammar, it seems to me that using sets as an intermediary would be the natural way to go, but I'm not aware of any Set to ICal generators (indeed, I'm not certain that all sets can even be expressed as ICal strings). Have I misunderstood your question? Matt P.S. Here is the code I am using to try and restrict the returned set where $now is a time in the last year and $end_date is $now + one year: %set_parms = (cron = $_, after = $now, before = $end_date); $cron_entry = DateTime::Event::Cron-from_cron(%set_parms);
DateTime marches on
I was recently making some long-needed updates to a relatively ancient module of mine, HTML::CalendarMonth. It's still pretty crufty as far as HTML generation is concerned, but no more crufty than HTML::Element. As I was slogging through a backlog of patches, bug reports, suggestions, etc, I began implementing some language i8n features for those that had requested it. In fact I released 1.10 with those mods in place. Then I took a second look at it and slapped my forehead. Two worlds, two minds. Despite following DateTime since its inception I never really thought to wed it with my calendar module because the calendar modules was not a pressing issue. Anyway, I'd gone part of the way down the road to doing exactly what DateTime::Locale does. So I quickly made an update, and now HTML::CalendarMonth 1.11 is fully powered on the i8n back end by DateTime::Locale. And it works splendidly. I guess my point is that if you stare at something in front of you long enough, sometimes, counter-intuitively, it never occurs to you to use it with something you've been staring at even longer. Thanks for all the work, folks. Mildly chagrined, Matt
Re: DateTime::Event::Crom command method
Hi Steve,
I'm not sure exactly why your entries are tripping up the module --
could you please send along an example line from the crontab in question
(doctor it up if there's anything private in it).
I do suspect what's happening, though -- the module attempts to
automatically detect when user names are present in the crontab file and
adjust accordingly (such as with the system cron files in Linux ...
/etc/crontab). Somehow that's getting tricked.
So disable it in your case. Try this:
my @entries = DateTime::Event::Cron-new_from_crontab (
file = '/tmp/crontab.out',
user_mode = 0
);
Let me know if that works.
Cheers,
Matt
Steve Sapovits wrote:
On Solaris 2.7, I only get command arguements -- not the whole
command -- if I do this:
use strict;
use DateTime::Event::Cron;
my @entries = DateTime::Event::Cron-new_from_crontab
(file = '/tmp/crontab.out');
my $entry;
foreach $entry (@entries)
{
print $entry-original(), \n;
print , $entry-command(), \n;
}
I get the whole crontab line, followed by the command
arguments only; i.e., the program name is missing.
All program names are full paths.
Any ideas why this isn't working as I'd expect? Or am
I missing something?
Re: DateTime::Event::Sunrise altitude angle
[EMAIL PROTECTED] wrote: Hi Joshua, I am not sure about this. I need to check with Paul to see if this is valid. Valid? Other than the patch he submitted appeared to not take into account a decimal place, there's nothing invalid about the suggestion. The regular expression encompasses values that are generally agreed upon to be civil/nautical/astronomical twighlight (i.e. dusk), plus when the lower disk of the sun touches horizon at sea level, middle of the sun, etc. Same for dawn. Other than these socially based standards, the same equations work perfectly well for arbitrary angles of elevation. Cheers, Matt
Re: install snafu with DT::F::MySQL
Ah, right. The problem is that DT::F::Builder includes the DT::F::MySQLmodules under its examples directory, and PAUSE is indexing it. I need to fix this somehow. Why not just bundle them together? CPAN will figure out which bundle to grab when you request a specific module such as DT::F::MySQL. (this only works if you're the maintainer of all modules in question...but I can imagine a scenario where you're bundling someone else's module in your examples directory and messing up their cpanitude...whoops) Matt
Re: Cron with TimeZone
Tim, My understanding with the current behavior is that if you set the time_zone for the set, that time zone will override the time zone of a datetime argument. Probably the easiest thing for you to do is to *not* set the time_zone of the set (since, as was previously discussed, it is actually a factory method rather than a mutator). Instead, just rely on setting the time zone of the original datetime. Using your example as a starting point, try this: --- use Datetime; use DateTime::Event::Cron; $cron = DateTime::Event::Cron-from_cron(cron = ' 15 18 * * 1-5'); $date = DateTime-new( year = 2004, month = 6, day = 30, hour = 17, minute= 10, time_zone = 'Europe/London'); print $date-strftime(%a %F %T %Z\n); $next = $cron-next($date); print $next-strftime(%a %F %T %Z\n); --- Produces: Wed 2004-06-30 17:10:00 GMT/BST Wed 2004-06-30 18:15:00 GMT/BST --- This be what you expect -- namely, each new datetime produced by next() will retain the time zone of the provided argument -- in this case, 'Europe/London'. The conversation regarding time zones and sets was rather scattered. I think in this case it might have obscured the most straightforward answer to your original question. Cheers, Matt
Re: Cron with TimeZone
Just to be clear, this is the native behavior of DateTime::Set, rather
than something that DateTime::Event::Cron is introducing into the sets
it generates. Using your same example, but replacing the cron set with
an actual (monthly) recurrence set, we see the same behavior:
---
$set = DateTime::Set-from_recurrence(
recurrence = sub {
return $_[0] if $_[0]-is_infinite;
return $_[0]-truncate( to = 'month' )-add( months = 1 )
},
);
$now = DateTime-now();
$next = $set-next($now);
print $next-strftime( %a %F %T %Z\n);
# Thu 2004-06-24 18:15:00 UTC
# but it should be floating time
$set = $set-set_time_zone('Europe/London');
$now = DateTime-now();
$next = $set-next($now);
print $next-strftime( %a %F %T %Z\n);
# Thu 2004-06-24 19:15:00 GMT/BST
# because it converted UTC=BST,
# instead of float=BST
$now = DateTime-now(time_zone = 'Europe/Berlin');
$next = $set-next($now);
print $next-strftime( %a %F %T %Z\n);
# Thu 2004-06-24 17:15:00 GMT/BST
# but it should be CEST
---
Cheers,
Matt
DateTime::Set, infinity, and recurrences
Hi All.
DateTime::Set was changed fairly recently in such a way as to
necessitate special handling of infinite datetimes in recurrences. This
isn't such a bad thing, but it does introduce complexity into even the
simplest of recurrences.
From the DateTime::Set docs:
# a 'monthly' recurrence:
$set = DateTime::Set-from_recurrence(
recurrence = sub {
return $_[0] if $_[0]-is_infinite;
return $_[0]-truncate( to = 'month' )-add( months = 1 )
},
span = $date_span1,# optional span
);
The operative line here is return $_[0] if $_[0]-is_infinite. This
line, or something similar, now needs to be added to recurrence
specifications in order to avoid an infinite loop.
My question is why can't this be done automatically? So the following
(consider this to be pseudo-code):
recurrence = sub {
return $_[0]-truncate( to = 'month' )-add( months = 1 )
},
would internally be converted to this:
recurrence = sub {
return $_[0] if $_[0]-is_infinite;
$recurrence(@_);
},
In case that's not clear -- take the intitial sub-ref and wrap the call
in another sub-ref that automatically deals with infinite values.
This would not break backwards compatability and would simplify the
lives of developers seeking simple recurrences.
If a developer really had a need for handling infinite values, then this
wrapping could be explicitely disabled with a parameter in the constructor.
Is this kind of nerfing of the API outweighed by the penalty of to
subroutine calls per iteration?
Thanks,
Matt
Re: DateTime::Set, infinity, and recurrences
We actually would be changing the current capability, if not the current behavior. Having 'detect_bounded' enabled by default would implement what I discuss but not break anything that already detects bounds on its own. Whether that's the right name or not...it seems okay to me, but other ideas would include 'handle_infinite' (default 1), or 'pass_on_boundaries' (default 0). Matt
Re: DateTime::Set, infinity, and recurrences
[EMAIL PROTECTED] wrote: If your recurrence specification is well-behaved, (don't use internals, etc) you don't have to test for infinite-ness. You only have to use return $_[0] if $_[0]-is_infinite; if your code can't handle DateTime::Infinite. As is wont with discussions of infinity, how to handle it can be pretty esoteric. I'd say 99% of the time (can't think of any counter examples) the right way to deal with infinity for next/previous *is* the line return $_[0] if $_[0]-is_infinite. But I suppose what you're really saying is that, since DateTime::Infinite is a type of datetime, the short-circuit return $_[0] if $_[0]-is_infinite is not necessary if the normal operations you're performing on your datetimes are correctly (i.e. defined) handled by DateTime::Infinite. Unless I'm missing something, it boils down to efficiency (why pointlessly run a DT::Infinite object through its paces) vs edge cases (probably some case of comparing a DT::Infinite to another DT::Infinite and thereby getting caught in an infinite loop). So rephrased, you're saying that if the next/previous routines in the recurrence are complicated enough to trip up DT::Infinite comparisons, then they should also be complicated enough to take that into consideration. I suppose I can buy that. So why have the guard clause in the simple examples presented in the DateTime::Set docs? Matt
Re: Cron with TimeZone
Tim,
As I said in response to your other email, the various
next/previous/iterator methods should respect the time zone of the
datetime object that you pass to them, so this should work:
my $cron = DateTime::Event::Cron-from_cron(cron = '* * * * *');
my $now = DateTime::Event-now(time_zone = 'Europe/Berlin');
my $next = $cron-next($now);
# $next will be in time zone Europe/Berlin
Recurrence sets can also be set to a default time zone. For example:
my $cron = DateTime::Event::Cron-from_cron(cron = '* * * * *');
my $now = DateTime-now(time_zone = 'local');
my $lcron = $cron-set_time_zone('Europe/Berlin');
my $next = $lcron-next($now);
# $next will be in the Europe/Berlin time zone, even if 'local' was not
I'm reasonably sure that in this last case, the time zone is converted
*after* all relevant calculations, so you will not inadvertently miss
any recurrence events due merely to a time zone leap.
Cheers,
Matt
Re: Cron with TimeZone
Hmm, Disregard the last note regarding the undefined value message -- buggy code without using warnings is to blame. Thanks, Matt
Re: DT::Duration overloads
Quoting Dave Rolsky [EMAIL PROTECTED]: With DateTime::Span: $mid_point = $span-start-add_duration( seconds = $span-duration-seconds / 2 ); With DateTime: $mid_point = $start-add_duration( seconds = $end-subtract_datetime_absolute( $start )-seconds / 2 ); Oh, duh! Why didn't I think of that. That's nice simple. If the operator overloads did that sort of thing behind the scene (and yes, with spans also), then it would be nicer and simpler. :) But thanks, Flavio and Dave, for the recipes and dealing with my questions. How about a DateTime::Span-midpoint method? Let's wait and see if others ask for it. For now, let's just add those recipes to the faq. Midpoints are compelling, but also arbitrary. I'd like to see the general problem of portioning a span, or the delta between two arbitrary datetimes (expressed as a span or otherwise, transparently), solved in a general way. After all, if midpoint is that common, sure, provide a method, but we don't need methods for thirds, quarters, eighths, forty-thirds, etc. Thanks again, Matt (in the Big Easy for a wedding...man I should get some sleep) P.S. Sorry for the wonky quoting in my earlier messages -- I plead inadequate mail client that can't properly convert between markup and plain text.
Re: DT::Duration overloads
Dave Rolsky wrote: Well, if you just want the _date_, it's pretty easy. my $dur = $dt1-delta_days($dt2); # or use Math::Round if you want my $mid = $dt1-add( days = int( $dur-delta_days / 2 ) ); If you want to account for the time then it gets funkier. Hmm, indeed. I need to approximate solar noon by deriving the midpoint between sunrise and sunset. I also need to approximate solar midnight by looking at the sunset from the prior day. As a general problem, finding a fractional time between two points in time is not that unusual. I *suppose* I could convert to epoch, take the diff, and use that to create a new duration. But it seems unfortunate that I'd have to step out of the datetime API like that. The two endpoints are known quantities -- there is no abiguity in selecting a midpoint. Is this sort of thing something that should exist in spans rather than expecting regular date math to handle? Matt
Re: DT::Duration overloads
Dave Rolsky wrote: Also, I'd like to point out that this really doesn't have as much to do with the internals as it does with the nature of date time math. You cannot expect to understand date math without understanding that it's not possible to convert between various units of date/time, in particular from months to days or vice versa. This would be a problem regardless of the internals, right? I do understand the ambiguities when you are dealing with various forms of durations that are not anchored to an actual point in time. As I said in my last message, however, we're talking about two absolute points in time -- no ambiguity. Rephrased, the question is again: what is the midpoint of a span? (and if we come up with a good approach to this problem, it should solve the general class of problems having to do with portioning out spans). It's not immediately apparent to me what the solution is -- I know what I want to do, and would prefer it to be fairly easy and straightforward. This seems to be an area of the interface that could use some brushing up rather than some intrinsic ambiguity of date math. (I'm willing to meditate on possible solutions myself -- I'm not merely asking you to solve it for me. However, I just thought I might be missing something obvious) Thanks again, Matt
DT::Duration overloads
I understand that division can be expressed as multiplication, but is there any particular reason why division (/) is not overloaded but multiplication is for durations? Then you could say: $midpoint = ($dt2 - $dt1)/2; rather than $midpoint = ($dt2 - $dt1) * 0.5; Small thing. Just curious. Thanks, Matt
Re: DT::Duration overloads
Dave Rolsky wrote: Thinking about this more, I'm considering maybe just requiring that multiplication be passed an integer, because if you do this: What I'd like to do is simply find the midpoint, more or less, between two arbitrary datetimes. Off the cuff, knowing nothing about the internals (which I do, but I'm pretending not to) I'd think this: $mid = $dt1 + ($dt2 - $dt1)/2 to dwim. However, as you say, things aren't really well defined the way durations are defined internally at the moment. So the question becomes -- if the above is not the datetime idiom for finding a midpoint between two datetimes, then what is? Thanks, Matt
Re: Moving to subversion?
Just on a usability note, I'm in favor. I've been using svn on several in-house projects over the last year or so, with no complaints -- well, setting up the server end is somewhat involved, but once it's set up you rarely have to visit it again. The added functionality (proper handling of directories, renaming, etc) are beyond worth it. Oh, for the OS X question, here's my first hit on google: http://www.pycs.net/bbum/2004/3/16/ Cheers, Matt
Re: DateTime::Stringify ...
David Wheeler wrote: So perhaps the eval will do the trick, esp. since one is generally generating a stack trace just before die'ing, so the run-time use of these constructs is not so questionable. I tried it both ways with no effect, in various scopes. I came to the conclusion, without delving into the innards, that the pragma is not universal, but specific to each scope in which it's used (which makes sense when you think about scope in perl ... e.g. 'use bytes' does not extend to packages you use). So in this case the no overload would only be of use in your particular package or class that uses it initially -- dipping into that sans permission, outside of subclassing, would be yet another ugly kludge. I could of course be missing much here -- it was only a cursory investigation where I twiddled some knobs in a test script/package. Matt
Re: DateTime::Stringify ...
Dave Rolsky wrote:
Well, right. But I'm talking about printing out a stack trace, ala Carp
or Devel::StackTrace. It prints out subroutine arguments, which may
include objects. If the objects are stringify to something like
'2004-01-02 11:12:13' then that could be kind of confusing if you're
expecting 'DateTime=HASH{0xDADADA}', right?
Right. Which is why Devel::StackTrace and Carp *ought* to be utilizing
overload::StrVal calls under those circumstances. From the overload POD:
overload::StrVal(arg)
Gives string value of arg as in absence of stringify
overloading.
Hence, buggy behavior from those digging tools. Perhaps we (or I)
should motivate and provide patches to those two projects.
Matt
Re: DateTime::Stringify ...
On second thought...probably a better approach would be for Devel::StackTrace and Carp to make liberal use of the no overload pragma. Matt
Re: DateTime::Stringify ...
Dave Rolsky wrote: Will that work? If so, I'll gladly add strinfication back, after changing Devel::StackTrace. Carp users will just have to deal ;) Hmmm, I guess not. At least, I couldn't get 'no overload' to do anything useful. How much of a PITA is it to use overload::StrVal and overload::Overloaded in Devel::StackTrace? Matt
Re: A Time-only namespace?
Daisuke Maki wrote: Now I noticed there isn't a namespace for this under DateTime. Is there any namespace that is recommended? I guess it may not make sense to put it under DateTime::, so would something like Time::Japanese work? I've always thought there should be support and functionality for 'clocks' (DateTime::Clock::*) that do not have to be connected to a calendar. I think the only thing that approaches this at the moment is DateTime::Incomplete. Matt
Re: Where's the official time zone for China?
Daisuke Maki wrote: I'm trying to set the default time zone for my DT::C::Chinese to the Chinese standard time zone so that people don't accidentally use their own time zones, only to get, for example, a Chinese new year date of Jan 21 2004 (UTC) instead of the official Jan 22 2004. Should the end result be converted to a floating time zone once you're through with calculations? That way it can be adapted to whatever local timezone the user is in: midnight Jan 22 2004 will be converted to local timezones during date math. (right?) Matt
Re: timezone data overlay -- an implementation
So did anyone actually bother to look at this? If it's good, let us know. If it's an abomination, let us know. Matt
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
Rick Measham wrote: 2. Create DateTime::TimeZone::Olson::XS - The Olson Database is already an open-source, free distributable C library, would we not save considerable space/memory by creating an XS interface to the library? You would still have to create the timezone singletons -- unless you're suggesting that these would be destroyed when not in use, you would still end up running into the same memory issues once enough timezone objects have been created. Matt
timezone data overlay -- an implementation
Here's a football to kick around over the weekend: http://www.mojotoad.com/sisk/dt/ Regarding the sharing of DT::TZ data across the timezone singletons, I've got an example implementation that demonstrates the principle. At the above URL you will find some modified versions of TimeZone.pm and parse_olson. In order to test you'll have to run parse_olson in your test distro -- something like tools/parse_olson --dir ./olson --version 2003d, presuming you've unpacked the Olson goods in ./olson. I've also included a 'tzt' script that shows some stats of the data sharing in action. What this stuff does is share data references, sometimes arrays, sometimes of certain objects, in all of the spots where they are repeatedly used across the timezone singletons. My solution will probably set of encapsulation klaxons in many of your minds -- but so long as these singletons are relatively static objects this should not be relevant. Some notes: 1) The data refs are handled via a _juxtaposition() class method 2) No preloading of zones or data is necessary. 3) There is a JUXTA_THRESHOLD constant that controls when this sharing behavior is invoked. Currently this is set to 25, so the sharing only starts happening if you're taking more than a walk around the world. Performance should not be impacted otherwise. 4) I'm currently taking the signatures of the data structures using Digest::MD5 and Data::Dumper. This is just the first way that came to mind, there could be better ways. 5) If we want to make dependencies on such modules optional, the sharing behavior can be made to invoke only if the requisite modules are present on the system. 6) Determining the signature of data structures could be made optional if we're willing to store the structures in a data file somewhere that could be queried at need. (not sure if I like that) 7) Coding style was off the cuff. If the behavior is deemed desirable, we can rework it more elegantly. 8) I was working off of the latest CVS versions. I'm unsure if it works with the latest CPAN release. So if you have time and the inclination, feel free to give it a whirl. Cheers, Matt
Re: DateTime::TimeZone issues...
Dave Rolsky wrote: 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. The timezone modules use lots of spans, correct? 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. Of course if there is no overlap of spans then the effort would be pointless. Matt
Re: DateTime::TimeZone issues...
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%. Matt
Re: DateTime::TimeZone issues...
Here's the script I used if you want to verify...
#!/usr/bin/perl
$sd = '/usr/lib/perl5/site_perl/5.8.0/DateTime/TimeZone';
my %Spans;
use File::Find;
use Data::Dumper;
-d $sd or die oops\n;
my $span_count = 0;
my $file_count = 0;
find (\wanted, $sd);
print TZ module count: $file_count\n;
print Span count: $span_count\n;
printCrunched: , scalar keys %Spans, \n;
exit;
sub wanted {
return unless /\.pm$/;
my $name = $File::Find::name;
open(M, $name) or die Problem opening $name\n;
my $olson = 0;
my $spans = 0;
my $str;
my $span;
while (M) {
++$olson if /Olson data version/;
next unless $olson;
if (/my\s+\$spans/) {
++$spans;
++$file_count;
next;
}
$str .= $_ if $spans;
if (/\];/) {
$spans = $olson = 0;
eval \$span = $str;
print oops: [EMAIL PROTECTED] if $@;
foreach (@$span) {
++$span_count;
my $str = Dumper($_);
++$Spans{$str};
}
$str = '';
}
}
}
#
Re: DateTime::TimeZone issues...
Dave Rolsky wrote: 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. As we saw in the beginning of this thread, there are some cases out there where people are faced with loading many, if not all, of the modules. This might be a minority of users, but I'd hate to see the problem become an impedement to the adoption of DateTime. 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 As for overhead and implementation. Perhaps a BEGIN block in each TZ module could populate the common data structure with each span array. I'm assuming that would be a hash, and the main thing required would be an efficient way to generate a unique key for each span. Then the same block would populate the private module-specific data structure with references to the shared span arrays. Once the data structure is built (compile time) there should be no further impacts on efficiency, but there is the extra cost of having to generate unique keys for each span at compile time. If you wanted to avoid the up-front cost, as well as the cost of unique key generation at compile/runtime, another option would be to have the program that generates the modules from Olson data pre-generate unique keys for each span. Then have a 'status' hash in each TZ-specific module that informs whether the module-specific spans have been inflated or not. If not, inflate them and store them in the common pool. Spans on demand, and only at the cost of a small list of unique keys in each TZ module. I'm probably missing some crucial detail, but on the surface of it I like the smell of the second option since it has virtually no additional performance impact from today's behavior. Matt
Re: DateTime::TimeZone issues...
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. No __DATA__ or external files will be required -- we'll just undef our private data once we're done populating the common structure when the module loads. Matt
DateTime::Format::ICal bug
DateTime::Format::ICal 0.08 is not passing the dog food test and successfully parsing its own results. For example: $DTFI = DateTime::Format::ICal; $r = $DTFI-parse_recurrence(recurrence = 'FREQ=DAILY'); $str = ($DTFI-format_recurrence($r))[0]; print $str\n; produces 'RRULE:FREQ=DAILY' Yet if we continue with that result... $r = $DTFI-parse_recurrence(recurrence = $str); We get an error: invalid freq () at ... DateTime/Event/ICal.pm line 557 At issue seems to be that the parser does not remove the 'RRULE:' part from the beginning of a rule before splitting on semicolons. Also, while we're at it, when we return these values can we either return a scalar when there is only one result (or make use of wantarray)? Thanks, Matt
parse_datetime and format_datetime
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? 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. Thanks, Matt
time zone class method? (DT::F::MySQL)
Was there a compelling reason not to have a class method analagous to
DefaultLocale() for timezones, such as DefaultTimezone()?
And if it were present, am I alone in finding it useful for the Format
modules, such as DT::F::MySQL, where the zoneless strings are forced
into the 'floating' timezone?
Although it is not strictly true that MySQL is timezone agnostic. You
could construct a local datetime using the result of MySQL's
UNIX_TIMESTAMP() function with DateTime's from_epoch() and set the tz to
'local' -- the unix timestamp returned from MySQL appears to observe the
timezone of the local machine.
As it now stands, DT::F::MySQL does not behave symmetrically for local
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?
Thanks,
Matt
Re: Mapping an offset to a datetime timezone
Dave Rolsky wrote: 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? It would be useful to be able to return a list of corresponding timezones, then the user could use whatever means they felt appropriate to select from the list (the application, I imagine, would be the determining factor in what this would be used for) Matt
Re: solar_longitude_after or modulo question
Yitzchak Scott-Thoennes wrote:
If you want to avoid use POSIX, floor is pretty easy:
sub floor { int($_[0]) - ( int($_[0]) $_[0] ) }
There's also lots of floor/ceil/round/nearest type functionality in
Math::Round that might be of interest:
http://search.cpan.org/~grommel/Math-Round-0.05/Round.pm
Matt
Re: More flexibly subtract/difference methods
Dave Rolsky wrote: 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. Rick Measham responded: Except, as Flavio points out, for non-gregorian calendars. Perhaps the Calendar classes can offer 'unit conversion' methods suitable for their particular idiom. Datetime could utilize these conversion methods when found, otherwise default to 'Gregorian' style calculations. Matt
Re: Olson - Microsoft mappings
Dave Rolsky wrote: 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. While this is true, it is also true that there are many countries that are *not* changing all of the time. Users in these countries might prefer a more intuitive UI for timezone selection rather than the pedantically correct bulk Olson listings. Put another way, if we can find a way to programatically categorize say 50% of the Olson DB, this still has value -- correct, it does not automatically digest the entire Olson DB, but if it captures 90% of the timezones in common usage then this effort still has value. Matt
Re: Hijri Calendar + searching datetime mail archives
Eugene van der Pijll wrote: Are you sure? I can't find any discussion (googling on e.g. islamic perl datetime finds only one or two posts), and I can't find anything in my 'sent' folder, and I'm almost sure I would have mailed in such a discussion. Hijri, Hejira, Hidjra...darn if I can figure out why I couldn't find squat on google! :) I'm not overly familiar with these calendars, although I know that the proper ones are lunar-based. As for my memory, I'm no doubt also conflating the Jalali discussion into the mix. It probably is accurate; but there are several (different) algorithms to calculate Hejira dates, used by different countries, and all of these are only approximations of the true dates, which are based on observations of the new moon. So we should be careful when we announce a module for _the_ DT::Cal::Hidjra. Right...I had taken a quick look at his code and knew that it must be a simplified version since it had no lunar component. If necessary, I'm willing to help converting it to a DateTime module; it's not that difficult, as the Gregorian=Hijrah conversion in Alex' module is already done via an absolute (rata-die) date. True. His post caught my eye because he mentioned it had been ported from some KDE code. I wasn't sure if their algo was particularly clever or worth capturing in DT. Cheers, Matt
Re: DateTime-localtime() (was Re: DT::TZ test failure)
Joshua Hoblitt wrote: Put a macro in your editor. :) I can appreciate your point of view on this. Consider, however, that DateTime will (and does) get used in quite a number of one off scripts and one-liners. I do it all the time for quick calculations where a full-blown script is unwarranted. That was more of what I had in mind when I referred to saving myself some typing. Let's not forget these little time saving idioms (ala 'print scalar localtime time'). Matt
Re: DateTime used with Class::DBI
Matthew McGillis wrote:
I have taken a look at the DateTime-Format-MySQL and it can produce
the formats required however with out being able to get the format
through a call as described above it will never work with Class::DBI.
Here's what I use in a similar situation...in the base class for my DB,
the one that inherits directly from Class::DBI, I have the following:
---
sub _register_dates {
my $class = shift;
$class = ref $class if ref $class;
foreach my $column (@_) {
$class-has_a(
$column = 'DateTime',
inflate = \_date_inflate,
deflate = \_date_deflate,
)
}
$class;
}
sub _date_inflate { DateTime::Format::MySQL-parse_datetime (shift) }
sub _date_deflate { DateTime::Format::MySQL-format_datetime(shift) }
Then, in any table-specific classes involving MySQL datetime fields, I
register the datetime columns thusly:
__PACKAGE__-_register_dates(qw(date_col1 date_col2 date_col3));
Seems to work well so far.
Cheers,
Matt
DT::F::DBI docs
There was a recent thread out on perlmonks regarding the functionality of DT::F::DBI: http://www.perlmonks.org/index.pl?node_id=274054 Basically the user did not realize they were dealing with a factory and that the API was actually documented, in their case, in DT::F::MySQL. Perhaps a note in the docs saying for more information see the documentation for the class pertaining to your particular dbh... Or is this supposed to be polymorphic behavior, with all the db format classes sharing the same API...in which case the API should then appear in the main docs? Cheers, Matt
Re: DT::Duration::Set
Dave Rolsky [EMAIL PROTECTED]: Can you and/or Joshua explain what this would be used for? elbowing in Unbounded clocks? Matt
Re: DT::Duration::Set
Can you expand on this please? I was terming a 'clock' as anything with periodicity. An 'unbounded' clock would be a clock without an associated epoch or starting date. A clock without context still has characteristics and can be compared to other clocks (for example, compare interval lengths). All the talk about duration sets, plus some earlier talk about time-only datetime objects, sounded like these concepts had a lot in common with clocks. (perhaps I'm just odd) Matt
Re: Slides from YAPC presentation
Surely there's some coffee shops or net cafes around with wireless and/or jacks? These days it's generally gratis so long as you buy a coffee every now and then. (haven't been paying attention, so I'm not sure exactly which city we're talking about) Matt
Re: DateTime::Duration nits...
[EMAIL PROTECTED]: Why not: $dur1 = new DT::Dur( days = 2 ); $dur2 = new DT::Dur( months = 1 ); $dur3 = $dur1 - $dur2; $dur3-add( days = 3 ); If you add $dur3 to a date, it would add 2 days and subtract a month, then add 3 days again. I love that this does the right thing. However, I don't see why it cannot be built into the constructor using negative values. The real snag is ordering, but this can be handled properly within the constructor (and adequately documented, not only for the constructor but for the general case). So, yes, the implication is that: $dur = DT::Dur-new(days = 2, months = -1); would indeed behave differently than: $dur = DT::Dur-new(months = -1, days = 2); So long as the behavior (intrinsic to durations) is well documented I think it stands to save lots of typing later. Matt
Re: DateTime::Duration nits...
Documented or not, it'll never be intuitive, which makes me think it's a bad idea. This could be a feature of the problem space rather than implementation. :) I'd say it's safe to say 99% of non-temporal geeks underestimate the subtle complexity of the problem...intuitive ends up being inconsistent. Matt (preaching to the choir)
parse/format_recurrence in DT::F::ICal
Is there some reason the parse/format routines for recurrences in DT::F::ICal are not documented in the POD? Is there anyhing wrong with these methods or is the lack of documentation an oversight? Thanks, Matt
DT::F::ICal format_recurrence
Found the parse_recurrence docs in the CVS, thanks. However, there's a good reason the format_recurrence method is not documented...it doesn't exist. Are there plans to implement this? Thanks, Matt
Re: DT::F::ICal format_recurrence
Quoting Dave Rolsky [EMAIL PROTECTED]: This is hard, since recurrences are implemented as closures/coderefs, and there's no way to look at one and figure out what it represents. Is it feasible, during construction, to leave enough bread crumbs around to reverse the process? (I would imagine DT::Event::ICal would be best positioned to understand the gap between the bread crumbs and actual construction) Matt
DateTime.pm now()
DateTime.pm claims to have a now() method equivalent to from_epoch() -- but there is no now(). Are there plans to use the request tracker on CPAN for this kind of thing, or this list the appropriate forum for now? (for the record, I like the notion of a now() method) Thanks, Matt
Re: DateTime.pm now()
DateTime.pm claims to have a now() method equivalent to from_epoch() -- but there is no now(). Scratch that -- I've sorted out my versions now. I'm still interested in this question, though: Are there plans to use the request tracker on CPAN for this kind of thing, or this list the appropriate forum for now? Matt
