Kirrily Robert wrote:
>
> Who's here? Can you please identify yourselves? I'm about to email ...
Hi, I am Flávio Soibelmann Glock. I wrote Set::Infinite, which includes
Set::Infinite::Date for schedule calculations.
- Flavio
David Dyck wrote:
>
> I noticed that a new version was just released but I'd like
> to request that the RCS/CVS generated version number in
> Date::ICal::Duration
> be bumped up, either to something 1.60 or greater or perhaps
> just apply the following patch (where I just add 1
> to whatever RCS
epoch_1990);
print " instead of ";
print $epoch_2000 -
$epoch_1990;
---
The following module was proposed for inclusion in the Module List:
modid: Date::Leapsecond
DSLIP: adpfp
description: translates between UTC and UT1 timescales
Yitzchak Scott-Thoennes wrote:
> How do you handle the future? Right now we only know the
> actual leap seconds through 2002/12/30. But you could make some kind of
> prediction for dates beyond that.
Sure, there could be an option, such that it would add 1 second
for each 1 1/2 year outside the
- these are valid datetimes too:
--10-11 # 10-11 current year
2001-300 # 300th day of 2001
- there also week-day formats, periods, and fractional times.
- Yahoo group "ISO8601" has some good references.
- Flávio S. Glock
see also: Date::Tie
[EMAIL PROTECTED] wrote:
>
> there d
(sorry, didn't send to the list)
--- Begin Message ---
Dave Rolsky wrote:
> I really dislike the way Date::Set relies on the
> ICal recurrence syntax for constructing objects and adding events. That
> syntax is way too confusing for humans to use, and we should use _data
> structures_, not comp
(sorry, didn't send to the list)
--- Begin Message ---
Rich Bowen wrote:
> I'm unclear how this is any less accurate than having a strictly seconds
> based method, and it means that we can store a wider range of dates in a
> smaller number.
Ok, I agree on using rata_die :)
Martijn van Beers wrot
Rich Bowen wrote:
> leap seconds seem kinda arbitrary. Is that just a table that you look up
> in?
Basically, yes.
Just like leap years, but there is no rule (there is no exact
calculations
for it).
Some (rarely) days will have one 0-60 seconds minute (instead of 0-59).
See also: Date::Leapsecon
Yitzchak Scott-Thoennes wrote:
> The iCalendar spec calls this a "floating" time
> and differentiates it from a UTC time or a time w/timezone (or a date
> without a time).
It's ok, Date::Set::Timezone already has 'local time' support (now I
know
it is called 'floating')
UTC times have a timezone
Dave Rolsky wrote:
> I think the main recise for fixed-point is to avoid rounding errors and
> allow for integer math. Or maybe I'm making that up. I'm no expert on
> date math.
Ok, Date::Tie has some special code for detecting special cases of
last-digit rounding errors (turns 0.99
Dave Rolsky wrote:
>
> On Mon, 13 Jan 2003, fglock wrote:
> > There is a licence is in the first lines of lib/Date/Set.pm.
>
> It should be in a LICENSE file in the top-level directory.
Done.
I just sent the latest Date::Set::Timezone (0.03) to CPAN.
Now I'm working on a D
Dave Rolsky wrote:
> Anyway, go ahead and send me a tarball and I'll import it. But let's talk
> API before you go too much further. I don't want to waste your time.
Here:
http://www.ipct.pucrs.br/flavio/perl/DateTime-Set-0.00_01.tar.gz
- Flávio S. Glock
Dave:
There was a bug in my tests. Here is the new version:
http://www.ipct.pucrs.br/flavio/perl/DateTime-Set-0.00_02.tar.gz
These are the news:
- Base object is DateTime.pm; there is no 'leaf' object
- The tests are NOT comprehensive, yet
- There are no changes to Date::Set::Timezone API
- D
Dave Rolsky wrote:
> I think the fundamental problem is that you don't have a good
> sense of what a user-friendly API would look like
That's why _you_ are in the project.
No, I don't think the problem is API or documentation.
The problem is that people don't get what a 'set' is.
We can't change
Warning Warning Warning:
I'm just attempting to explain how these things would be done
if you were using Set::Infinite API.
> while ( my $dt = $dt_iterator->next( sort => 'asc' ) )
- first() returns "head and tail" of a set, as if it were a list of
subsets:
while ( ($dt, $dt_iterator)
Dave Rolsky wrote:
> Oooh, we'll use Quantum::Superpositions! Hehe, that should satisfy
> everybody.
:)
This is _the_ authoritative site on leap seconds:
http://hpiers.obspm.fr
UT1 is the time scale based on the observation of the Earth's rotation.
UTC is derived from UT1 by adding leap sec
Just another proposal for starting DateTime::Set
- Inherit Set::Infinite "as-is". No new API, just make it work.
- No epoch-related internals. All math is handled by DateTime.pm
- No parsing or stringification.
What you get:
- A toolkit for building a new API
- Basic functions: union(), inte
Dave Rolsky wrote:
>
> > About the timezone stuff, now you can use the Date::Set until() method
> > to join recurrences the way they are specified in rfc2445/Olson.
>
> Is this documented? Or is it in an as-yet-unreleased version?
It is a Set::Infinite method:
=head2 until
Extends a set until
Dave Rolsky wrote:
> Instead of epoch internals, BTW, I
> think we can simply use something like ICal or some other string based
> format, since those can be compared properly as well. The only question
> is whether "-01001010T101022" is less than "01000101T101022", and from the
> command line qui
Another reference, nice to read:
http://mathforum.org/library/drmath/view/52475.html
Dave Rolsky wrote:
> So does anybody reading this object to me changing the default time zone
> to UTC? I think UTC is better than floating here simply because it's
> easier to explain.
I understand that a 'floating' date object has less information on it
than a 'UTC' date object, since the float
About moving perl-date-time to CPAN:
The modules will be published by their authors or by
the project administrators?
I suggest making a Bundle too.
- Flávio S. Glock
--
In a parallel DateTime:
http://lwn.net/1998/0402/a/datetime.html
published in CPAN as:
http://sea
DateTime::Set 0.00_07 will soon be in CPAN.
note: the API is not stable.
- Flavio S. Glock
NAME
DateTime::Set - Date/time sets math
SYNOPSIS
use DateTime;
use DateTime::Set;
$date1 = DateTime->new( year => 2002, month => 3, day => 11 );
$set1 = DateTime::Se
n in Set::Infinite pod,
to help other people understand the code.
> the docs in DateTime::Set are not clear enough
My fault, I will try to do better.
There _was_ a discussion in the datetime list a while ago:
On Mon, 20 Jan 2003, fglock wrote:
> Just another proposal for starting DateTi
round() - new DateTime method proposal
The round() method would do to a DateTime what "int" does to scalars:
remove some fractional information.
Example:
$date->round( 'day' );
would be the same as:
$date->set( day => 1, hour => 0, minute => 0, second => 0 );
The rationale for this is
fglock wrote:
> $date->round( 'day' );
> would be the same as:
> $date->set( day => 1, hour => 0, minute => 0, second => 0 );
bugfix:
$date->round( 'day' );
would be the same as:
$date->set( hour => 0, minute => 0, second => 0 );
- Flavio S. Glock
Dave Rolsky wrote:
> On Thu, 6 Mar 2003, fglock wrote:
> > What about this (see my other e-mail):
> >
> > $days = DateTime::Set->new( recurrence => sub { $_[0]->add( days => 1
> > ) },
> > start => NEG_INFINITY,
&g
Dave Rolsky wrote:
> The level of truncation needed can be calculated
pretty easily.
Yes, if I have a recurrence string (like RFC2445
recurrences).
But I don't see how to calculate it from a piece of
callback code that could be specifying things so
widely variable, from milliseconds up
> The sub that generates recurrences can be responsible for truncation, right?
Yes, but it needs to know "which" truncation to do. I think we could use an interface
like this:
new( callback => sub { . }, freq => 'year' );
The callback would be called with a parameter like "2003-01-01" (bec
> The sub that generates recurrences can be
responsible for truncation, right?
Right! I just found a way:
The callback receives a DateTime parameter. The
callback must return 2 values: the value of the
recurrence just before the date (that is, the
truncated value), and the value of the recurr
Oops. There was an error in my example, I didn't
truncate the second return value.
> Why does the DateTime::Set class need to get both
dates back? I think that's what is confusing me.
It needs 'random access' to the recurrence, such that
it can construct the set of ocurrences for a give
> Why does the DateTime::Set class need to get both
dates back? I think that's what is confusing me.
Another option: the callback receives a start date
and an end date parameters, and it returns the list
of the dates that are in that time span. This looks
much simpler, and it solves the pro
> Why does the DateTime::Set class need to
get both dates back? I think that's what
is confusing me.
> Another option: the callback receives a
start date and an end date parameters, and
it returns the list of the dates that are
in that time span. This looks much simpler,
and it solves th
I propose
DateTime::Set->new( recurrence => $string
);
where $string is any of the parameters
accepted by both DateTime::truncate() and
DateTime::add(), such as 'day', 'year'.
If somebody really wants other recurrences,
they could create their own
DateTime-derived class and override
> On Thu, 13 Mar 2003 [EMAIL PROTECTED] wrote:
>
> >> Dave wrote:
> >> In pseudo-code, I'd do ...
>
> > I'm writing some code to test it.
It works!
..->new(
recurrence => sub { ... },
start => optional,
end => optional,
}
should I commit this?
- Flavio S. Glock
Yitzchak Scott-Thoennes wrote:
> use constant INFINITY => 100 ** 100 ** 100 ;
> use constant NEG_INFINITY => -1 * (100 ** 100 ** 100);
>
> I remember this (how to produce an numeric infinity) coming up on
> perl5-porters and seem to recall that the above just coredumps on some
> platform
Yitzchak Scott-Thoennes wrote:
> On another topic, just below add_duration in DateTime.pm, I see this:
>
> use constant INFINITY => 100 ** 100 ** 100 ;
> use constant NEG_INFINITY => -1 * (100 ** 100 ** 100);
>
> I remember this (how to produce an numeric infinity) coming up on
> perl5-
If I'm truncating a date to 'month', is because I want a date with
'integer-months'.
Just like if I truncated a number to 'integer' - I get an integer
number, isn't it?
See also:
http://www.redhat.com/docs/manuals/database/RHDB-7.1.3-Manual/sql/functions-datetime.html#FUNCTIONS-DATETIME-TRUNC
[..
I'm not sure of how the DateTime::Set iterator should
behave.
Would you give me an example? I've got a sketch:
if ( $set->is_infinite ) {
warn "this is an infinite set";
print "first date is ", $set->min;
print "second date is "
print "last date is ", $set->max;
}
else {
> I was thinking of something like this actually:
> my $iterator = $set->iterator
> while ( my $dt = $iterator->next ) { ... }
>
> The iterator() method may need to take some
parameters, like "start" and "end" for infinite sets,
as well possible a direction parameter as well.
> It will return
> No, I was thinking more for internal implementation
There is no need for a different iterator.
Internally, everything are "sets".
You could create a set using
new DateTime::Set( day => 3, every => 'month' )
and then use the same iterator that works with
callbacks.
> Anyway, the start and
> Is DateTime at a mature-enough stage where I could
do this without annoying my users - all 6 of them ;-)
- when things break?
Maybe it is not ready for a Date::ICal release in
CPAN yet, but we could have a version in CVS.
> If you want to send patches, or commit them
yourself (I think you h
Dave Rolsky wrote:
> It can go under modules/ if Rich is ok with moving the CVS. But I for one
> wouldn't want to move it without preserving the version history, which
> requires SourceForge staff help.
The version history is not very important at this point, because I'm
actually working on a bra
The module is here:
http://www.ipct.pucrs.br/flavio/perl/Date-ICal-2.03.tar.gz
It passes all tests, and it works with my old programs, too.
Rich Bowen wrote:
> I can put in this request if desired.
Right. I think it is better to continue this work under perl-date-time.
Implementation notes:
(o
Dave Rolsky wrote:
> On Mon, 17 Mar 2003, fglock wrote:
> > However, there are some functions that don't have tests, and are not
> > marked 'internal', such as offset_from_seconds().
> This should probably use DateTime::TimeZone's functions for han
- DateTime::Set 0.00_13 was sent to CPAN.
It implements most of the API that was discussed here.
Please upgrade to the latest DateTime, and to Set::Infinite 0.44,
before testing it.
- Fixed a typing error in Date-ICal day_of_week()
http://www.ipct.pucrs.br/flavio/perl/Date-ICal-2.04.tar.gz
Dave Rolsky wrote:
> How could a set of discrete datetimes also be a
> set of spans?
Mmm, it's like 'spans with zero-duration', but maybe
we just don't need that, actually.
> > $set1 = DateTime::SpanSet->new(
> > spans => [ $dt_span, $dt_span ] );
> I think this is necessary.
Ok. Maybe
DateTime::Timezone from CVS doesn't pass tests:
t/02basic.t -> there is no method all_names (although
it is in the docs)
t/03link.t -> seems like it can't find 'America/Chicago'
(this is RedHat Linux 7.3)
- Flavio S. Glock
Dave Rolsky wrote:
> > $set1 = DateTime::SpanSet->new( start_set
=> $dt_set, end_set => $dt_set );
> What would this create exactly?
This is the same thing, but with another syntax (I
prefer this one):
$set_start = new DateTime::Set( $day1, $day3 );
$set_end = new DateTime::Set( $day2, $
Dave Rolsky wrote:
> I think the API needs to be simple and encourage simplicity in its use,
> because this is a complicated area.
Ok. This one is rather simple:
$dt_spanset = $dt_set->to_SpanSet( duration => $dt_one_month );
Converts this DT::Set
2002-01-01 ,
2003-01-01
to this DT::Sp
Dave Rolsky wrote:
> You have to run tools/parse_olson in order to generate the individual time
> zones modules and DateTime::TimeZoneCatalog.
Oops.
It would be useful if the tests would tell you that, on failure.
Or maybe Makefile.PL would call tools/parse_olson if you asked politely.
- Flavio S
All methods are DateTime wrappers; all tests pass.
- Thanks to Dave Rolsky for helping with bugs!
- The functions jd2greg(), greg2jd() are still "native".
- I think jd() and julian() are internals, may I remove them?
- Is it ok to commit this to Reefknot CVS?
http://www.ipct.pucrs.br/flavio/perl/D
Dave Rolsky wrote:
>
> On Fri, 21 Mar 2003, fglock wrote:
>
> > All methods are DateTime wrappers; all tests pass.
> > - Thanks to Dave Rolsky for helping with bugs!
> > - The functions jd2greg(), greg2jd() are still "native".
>
> You should use _rd2ym
Dave Rolsky wrote:
> I suppose I could include a pure Perl solution. What is your barrier to
> using XS?
That's something I'd like too.
I could test my code on Windows, without having to wait until someone
compiles it for me.
- Flavio S. Glock
Dave Rolsky wrote:
> > > You should use _rd2ymd and _ymd2rd. These are much faster cause they're
> > > written in C in DateTime.xs.
...
> The thing is that when Date::ICal says jd there it's lying because it
> really produces Rata Die days! In fact, those functions are the same as
> what DateTime
Is it ok to have a "to_DateTime" function in Date::ICal ?
$dt = $d_ical->to_DateTime()
Such that you can do tricks with non-DateTime modules:
use Date::Passover;
$dt = passover( 1997 )->to_DateTime;
- Flavio S. Glock
Dave Rolsky wrote:
> On Fri, 21 Mar 2003, fglock wrote:
> > Dave Rolsky wrote:
> > > You have to run tools/parse_olson in order to generate the individual time
> > > zones modules and DateTime::TimeZoneCatalog.
> > It would be useful if the tests would tell y
We need some functions to find out what's inside a set, besides the
"iterator".
I think we need at least these, but I'd like if you would suggest more,
and maybe better names:
->is_infinite_set
->is_empty_set
->is_closed_start
->is_closed_end
More options (negative of the above):
->is_
A. van Roggen wrote:
> if the switch was made at the start of 1600.
Maybe this?
$dt = new Modulename (
year => x, month => x, day => x,
switch_year => 1600
);
- Flavio S. Glock
Dave wrote:
> - DateTime::EventSet
I like this one.
It could be "virtual", in that
DateTime::EventSet::xxx
would be available if you had
DateTime::Event::xxx installed.
---
I propose the DateTime::Event semantics
be changed to: "returns the _next_ event after the date"
Example: DateTime::Ev
> My question is .. should they return midnight?
> If its noon on the 4th
> July and we ask for 'next' or 'set' do we
> include the current?
> Probably not.
agree.
> But if we return midnight, does
> 'previous' return the
> current? Really shouldn't.
agree.
- next() returns ">",
- prev() r
> Anyone have a recommendation for some simple FAQ
management software that datetime.perl.org could use?
perlmonks.org has a Perl FAQ section.
Maybe we could use it?
- Flavio S. Glock
Dave Rolsky wrote:
> Looking at the code this seems to be based on the highly dubious
> assumption that no two dates produced by a recurrnce could be great than
> 13 months apart.
> What if you recurrnce is "once every century"?
I was actually going to rewrite that part.
The new idea was, it would
Hill, Ronald wrote:
> I just completed the changed to the module.
> let me know if I need to change anything else.
- maybe arguments should be 'longitude' instead of 'LON' ?
- POD says 'DateTime::Astro::Sunrise' instead of
'DateTime::Event::Sunrise'
- Flavio S. Glock
Eugene van der Pijll wrote:
> By the way, I can't find the algorithm for Eastern Easter in Tondering's
> Calendar FAQ anymore. Here is a page with an excerpt of an older version
> of the algorithm: http://www.smart.net/~mmontes/ortheast.html .
Try this :)
http://www.google.com.br/search?q=tonderin
DateTime::Event API suggestion,
based loosely on the DateTime::TimeZone API:
my $ev_sr = DateTime::Event->new(
name => 'Sunrise/sunrise' );
my $ev_ss = DateTime::Event->new(
name => 'Sunrise/sunset' );
my $ev_ea = DateTime::Event->new(
name => 'Easter' );
my $dt_set = $ev_sr->as_set;
my
> I suspect that same goes for some Asian languages.
by the way, I think that the languages we have are
using "latin1".
Maybe we should make it UTF8.
- Flavio S. Glock
I've finally got the set generation (sunrise, sunset)
and span-set (daylight time, night time) working
properly.
http://www.geocities.com/fglock/sunrise_test.tar.gz
Require latest DateTime::Set/Span/SpanSet from CVS.
- Flavio S. Glock
RFC: how to name these parameters to the
DateTime::SpanSet->new() method:
#1 - Building a SpanSet from
2 recurrence callbacks:
$set = new DateTime::SpanSet (
starting_recurrence_sub => sub { .. },
ending_recurrence_sub => sub { .. },
);
#2 - Building a SpanSet from
I noticed DateTime::Duration <=> is not
checking the 'reverse' flag.
Also, it would be useful to be able to
compare a duration to zero, in order to check if
it is negative, positive or null.
I could do that, just tell me if it is ok.
- Flavio S. Glock
.. or maybe "DateTime::Event::Base"
Dave wrote:
> I think the problem is that this (AFAICT) forces
> all events to be dealt with as sets internally,
> which may not be what many module authors want
> to do.
No, that's not the idea.
What I propose is a common API.
If the module author wants to
Dave Rolsky wrote:
> I thought about this a
> bit more and realized I don't really like it,
because it special cases one
> number, zero. But comparing it to other numbers
wouldn't make sense.
Ok. Maybe a $dt_dur->is_zero() method instead?
- Flavio S.
Glock
Bruce Van Allen wrote:
>
> 1. This is one reason some us have argued for the
capability of caching
> recurrence sets (which Flavio implemented!).
I'm not done yet - but I've got it started.
> Brad suggests another way
> to accomplish this, which would have application in
some uses:
> > In any
>
> Just out of curiosity, how come DateTime has + and
- overloaded, but
> DateTime::Duration doesn't?
Because I didn't need it :)
I only implemented multiplication.
Put it on my TODO list...
- Flavio S. Glock
> >
> > Just out of curiosity, how come DateTime has + and
> - overloaded, but
> > DateTime::Duration doesn't?
>
> Because I didn't need it :)
> I only implemented multiplication.
> Put it on my TODO list...
I just checked it - it _does_ overload + and - !
- Flavio S. Glock
> Please could you tell me what the dates for Rosh
> Hashana are for the
> next 3 years?
>
> Thanks
> B Hyman
Start with:
use Date::Passover;
($month, $day ) = roshhashanah( 2003 );
- Flavio S. Glock
May I import Date::Leapsecond into
"modules/DateTime.pm/lib/DateTime/Leapsecond.pm"?
I could then make the changes in DateTime to use it.
- Flavio S. Glock
In DateTime::Duration:
sub new():
...
unless ( grep { $self->{$_} } qw( months days ...
{
$self->{sign} = 0;
}
and then:
sub is_positive { $_[0]->{sign} == 1 ? 1 : 0 }
which makes a zero-duration be "not positive",
because sign is zero.
- Flavio S. Glock
Joshua Hoblitt said:
> There must be a way to express the same semantic
> meaning with fewer lines of code
A slightly smaller version - specify days and hours
in the same constructor.
- Flavio S. Glock
---
#!/usr/local/bin/perl -w
use strict;
use DateTime;
use DateTime::Span;
use DateTime::Span
http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.
html
"... Since the system was introduced in 1972, "
The table starts in 1972. Before that, GMT was
in use - not UT1!
- Flavio S. Glock
Thanks Eugene.
I'll try to rephrase this, because it
would be good to have it in the FAQ.
If somebody can explain it better, or
more correctly, please help me!
What's up with GMT, TAI, UTC, and UT1?
Before 1972, the "international time" reference
was GMT. In GMT, all days have the same number
Jay Lawrence _is_ working on the .ics file parser:
package Text::vFile::Base;
...
=item load_singleDate
Loads a date creating a DateTime::Format::ICal
object. Thanks Dave!
=cut
...
=item load_singleDuration
Loads a data duration using DateTime::Format::ICal.
=cut
(from Text:
Here is my ICS file parser prototype,
using Text::vFile.
I think it can't go into DT::Format::ICal,
because it would cause a circular dependency
through Text::vFile. Is this a problem?
I implemented just enough for it to
understand the ics files from
http://www.apple.com/ical/library/
- Flavio
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.
This is not too difficult to implement.
Is it too confusing?
- Flavio S. G
> [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 thi
They are documented in CVS version.
> 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?
We could add an optional parameter to DateTime::Set
recurrence constructor:
$r = new DT::Set {
recurrence => sub { next_day($_) },
as_ical_string => "RRULE:FREQ=DAILY",
}
DT::E:Cron, DT::E:Recurrence, DT::E:ICal can use
this to setup a valid ICal string.
In some case
Ok, I've got DateTime::Set::ICal implemented under
DT:E:Recurrence. It's an 'internal use' class for
recurrences that can be represented using ICal
statements.
DT::Format::ICal can now format pretty complex sets
as ICal statements:
example from t/04recurrence.t:
..
my $exclude = $union2->union(
> I assume that this only works for things created by
> ICal...
Right now it works for:
- any _bounded_ set, spanset, span, datetime
- any unbounded DT:E:ICal set
- union()s of those objects
- union()s followed by complement()s
Other unbounded set operations are not
representable with ICal, but
That's all correct, and the implementation is
cut-and-paste DT::Set/DT::E::Recurrence code.
Dave wants to know _why_ we want this!
- Flavio S. Glock
> > Of course, this will not allow for
duration-recurrences.
>
> Aren't recurrences basically a set of durations at
fixed intervals? Could durat
Dave:
I think it would be good to integrate
DT::Event::ICal,
DT::Format::ICal and
DT::Set::ICal in a single distribution.
This would make it easier to manage dependencies
and version checking between them, and we would
have a single, comprehensive test suite.
It would make it easier to in
> Maybe there is something fundamental we can boil
> out of DT::E::R. hmmm...
I found out a way to get a duration-set out
of DT::E::R:
$dt_set = new DT::E::R( %param ); # datetimes
$dur_set = $dt_set - $dt; # durations!
It will not work under the current implementation,
but it can be done.
It would be easy to change the Perl code generator
into a C code generator. Then you could use
DT::LeapSecond at compile time, if they are using
XS, or at runtime, if they are using pure Perl.
- Flavio S. Glock
The idea is: you call DT::LS from _DateTime_
Makefile.PL, and it generates C source code
that compiles with DT XS - it makes a C
include file - it is not a DT::LS XS library.
Dave Rolsky wrote:
>
> On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
>
> > It would be easy to change the
Eugene van der Pijll wrote:
>
> I would prefer if this:
>
> DateTime::Incomplete->new( year => 2003 );
>
> would create the incomplete dt
> 2003-xx-xxTxx:xx:xx; that is: the
> defaults of the DT::I constructor should be
> 'unknown'. That simplifies the creation of DT::I
> objects, and is t
- DateTime::Incomplete 0.00_03
Most functionality discussed in the DT::Complex
thread is implemented.
Mayan calendar datetimes should work, but it
has not been tested!
There are a few missing bits:
no has_month() - but has('month') is ok.
no fields()
no base_class()
there is no def
Flavio S. Glock wrote
> There are a few missing bits:
>
> no has_month() - but has('month') is ok.
Now month() and has_month() are ok!
- Flavio S. Glock
I'm trying to figure out how to allow
for incomplete year/month/day, year/week/day,
or year/day in DT::I.
One way is to have a separate implementation
for each case:
DateTime::Incomplete
year / set_year
month / set_month
day / set_day
DateTime::Incomplete::YearWeekDay
week_year / set
Joshua Hoblit wrote:
>
> > I'm trying to figure out how to allow
> > for incomplete year/month/day, year/week/day,
> > or year/day in DT::I.
> >
> > One way is to have a separate implementation
> > for each case:
>
> Is it possible express all of these as:
>
> If year is known:
>
> a DateTime +
How about DateTime::Incomplete::Agnostic ?
You can convert it to Christian, Jewish, ... :)
- Flavio S. Glock
Dave Rolsky wrote:
>
> > DateTime::Incomplete::Agnostic - base class
> >
> > to_datetime
> > next / previous / etc.
> >
> > Another approach: the API would remember what
methods were
1 - 100 of 169 matches
Mail list logo