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
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
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
[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
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
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
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
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
Dave Rolsky [EMAIL PROTECTED]:
Can you and/or Joshua explain what this would be used for?
elbowing in
Unbounded clocks?
Matt
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).
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
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
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.
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
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
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
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:
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
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'
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
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'
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
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
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;
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
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
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
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
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
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
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
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
On second thought...probably a better approach would be for
Devel::StackTrace and Carp to make liberal use of the no overload pragma.
Matt
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
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
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
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.
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
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
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
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(
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 =
Hmm,
Disregard the last note regarding the undefined value message -- buggy
code without using warnings is to blame.
Thanks,
Matt
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 =
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:
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
[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
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
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
[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
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
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
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
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.
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
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
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
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
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,
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:
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
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
62 matches
Mail list logo
