Re: rollcall!

2001-08-13 Thread fglock
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

Re: Date::ICal::Duration version

2002-03-07 Thread fglock
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

Date::Leapsecond

2002-05-29 Thread fglock
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

Re: Date::Leapsecond

2002-05-31 Thread fglock
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

Re: propose submition- DateTime::ISO

2002-07-15 Thread fglock
- 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

[Fwd: Re: Internals (Re: Date::ICal's pseudo-mjd)]

2003-01-13 Thread fglock
(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

[Fwd: Re: base object and internals]

2003-01-13 Thread fglock
(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

Re: Leap seconds

2003-01-14 Thread fglock
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

Re: timezones

2003-01-14 Thread fglock
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

Re: fixed-point

2003-01-14 Thread fglock
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

DateTime::Set

2003-01-14 Thread fglock
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

Re: DateTime::Set

2003-01-14 Thread fglock
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

Re: Date::Set

2003-01-14 Thread fglock
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

Re: Date::Set

2003-01-15 Thread fglock
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

Re: DateTime::Set API

2003-01-16 Thread fglock
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)

Re: timezones

2003-01-17 Thread fglock
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

Re: DateTime::Set API

2003-01-20 Thread fglock
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

Re: Date::Set::ICal a bit broken

2003-01-20 Thread fglock
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

Re: DateTime::Set API

2003-01-22 Thread fglock
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

Re: There _is_ a (Gregorian) year 0

2003-02-26 Thread fglock
Another reference, nice to read: http://mathforum.org/library/drmath/view/52475.html

Re: DateTime bug & default timezone

2003-02-27 Thread fglock
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

perl-date-time

2003-02-27 Thread fglock
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

2003-02-28 Thread fglock
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

Re: DateTime-Set.pm

2003-03-05 Thread fglock
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() - DateTime method proposal

2003-03-05 Thread fglock
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

Re: round() - DateTime method proposal

2003-03-05 Thread fglock
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

Re: DateTime-Set.pm

2003-03-07 Thread fglock
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

Re: DateTime-Set.pm

2003-03-07 Thread fglock
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

Re: DateTime-Set.pm

2003-03-10 Thread fglock
> 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

Re: DateTime-Set.pm

2003-03-10 Thread fglock
> 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

Re: DateTime-Set.pm

2003-03-10 Thread fglock
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

Re: DateTime-Set.pm

2003-03-11 Thread fglock
> 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

Re: DateTime-Set.pm

2003-03-12 Thread fglock
> 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

Re: DateTime-Set.pm

2003-03-12 Thread fglock
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

Re: DateTime-Set.pm

2003-03-13 Thread fglock
> 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

Re: DateTime bug & default timezone

2003-03-14 Thread fglock
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

Re: DateTime bug & default timezone

2003-03-14 Thread fglock
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-

Re: truncate() semantics

2003-03-14 Thread fglock
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 [..

DateTime::Set iterator

2003-03-15 Thread fglock
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 {

Re: DateTime::Set iterator

2003-03-15 Thread fglock
> 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

Re: DateTime::Set iterator

2003-03-15 Thread fglock
> 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

Re: Date::ICal

2003-03-16 Thread fglock
> 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

Re: Date::ICal

2003-03-17 Thread fglock
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

Re: Date::ICal

2003-03-17 Thread fglock
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

Re: Date::ICal

2003-03-17 Thread fglock
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

2003-03-19 Thread fglock
- 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

Re: DateTime::Set API - constructors

2003-03-20 Thread fglock
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 doesn't pass tests

2003-03-20 Thread fglock
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

Re: DateTime::Set API - constructors

2003-03-20 Thread fglock
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, $

Re: DateTime::Set API - constructors

2003-03-21 Thread fglock
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

Re: DateTime::Timezone doesn't pass tests

2003-03-21 Thread fglock
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

ANNOUNCE: Date-ICal 2.06

2003-03-21 Thread fglock
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

Re: ANNOUNCE: Date-ICal 2.06

2003-03-21 Thread fglock
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

Re: XS in DateTime.pm

2003-03-21 Thread fglock
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

ANNOUNCE: Date-ICal 2.07

2003-03-21 Thread fglock
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

Date::ICal to DateTime

2003-03-21 Thread fglock
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

Re: DateTime::Timezone doesn't pass tests

2003-03-21 Thread fglock
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

DateTime::Set API - functions

2003-03-21 Thread fglock
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_

Re: ANNOUNCE: DateTime::Calendar::Julian 0.03

2003-03-22 Thread fglock
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

Re: DateTime and Holidays

2003-03-22 Thread fglock
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

Re: DateTime and Holidays

2003-03-22 Thread fglock
> 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

Re: FAQ manager?

2003-03-23 Thread fglock
> 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

Re: DateTime::Set previous?

2003-03-24 Thread fglock
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

Re: DateTime::Event::Sunrise Beta

2003-03-24 Thread fglock
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

Re: DateTime::Event::Easter Beta1

2003-03-24 Thread fglock
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

2003-03-24 Thread fglock
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

Re: DateTime::Language

2003-03-31 Thread fglock
> 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

RE: working on the as_set portion of the sunrise module

2003-03-31 Thread fglock
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: DateTime::SpanSet new()

2003-03-31 Thread fglock
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

DateTime::Duration compare

2003-04-04 Thread fglock
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

Re: RFC: DateTime::Event::Basic

2003-04-05 Thread fglock
.. 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

Re: DateTime::Duration compare

2003-04-05 Thread fglock
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

Re: What should a business module implement?

2003-06-06 Thread fglock
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

Re: DateTime::Duration arithmetic (why isn't it overloaded?)

2003-06-04 Thread fglock
> > 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

Re: DateTime::Duration arithmetic (why isn't it overloaded?)

2003-06-04 Thread fglock
> > > > 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

Re: Dates for Rosh Hashana

2003-06-07 Thread fglock
> 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

leap seconds

2003-04-12 Thread fglock
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

DateTime::Duration is_positive bug?

2003-06-10 Thread fglock
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

Re: date normalization

2003-06-16 Thread fglock
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

Re: Getting different results from DateTime and Manip for epoch time

2003-06-22 Thread fglock
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

Re: Getting different results from DateTime and Manip for epoch time

2003-06-22 Thread fglock
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

Re: DateTime and .ics files

2003-06-28 Thread fglock
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:

Re: DateTime and .ics files

2003-06-28 Thread fglock
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

Re: DateTime::Duration nits...

2003-06-30 Thread fglock
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

Re: DateTime::Duration nits...

2003-06-30 Thread fglock
> [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

Re: parse/format_recurrence in DT::F::ICal

2003-06-30 Thread fglock
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?

Re: DT::F::ICal format_recurrence

2003-07-01 Thread fglock
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

DateTime::Set::ICal

2003-07-03 Thread fglock
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(

Re: DateTime::Set::ICal

2003-07-03 Thread fglock
> 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

Re: DT::Duration::Set

2003-07-04 Thread fglock
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

DT::*::ICal modules

2003-07-05 Thread fglock
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

Re: DT::Duration::Set

2003-07-05 Thread fglock
> 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.

Re: integrate leap seconds with core XS code?

2003-07-13 Thread fglock
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

Re: integrate leap seconds with core XS code?

2003-07-13 Thread fglock
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

Re: RFC: DateTime::Complex

2003-07-18 Thread fglock
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

ANNOUNCE: DateTime::Incomplete 0.00_03 in CVS

2003-07-21 Thread fglock
- 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

Re: ANNOUNCE: DateTime::Incomplete 0.00_03 in CVS

2003-07-21 Thread fglock
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

RFC: DateTime::Incomplete

2003-07-24 Thread fglock
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

Re: RFC: DateTime::Incomplete

2003-07-24 Thread fglock
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 +

Re: RFC: DateTime::Incomplete

2003-07-24 Thread fglock
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   2   >