On Tue, Jan 14, 2003 at 12:27:30AM -0600, Dave Rolsky wrote:
> On Mon, 13 Jan 2003, Martijn van Beers wrote:
>
> > gives:
> > [19700329T02..19701025T03],
> > [19710328T02..19711031T03],
> > [19720326T02..19721030T03]
> >
&g
On Mon, Jan 13, 2003 at 09:14:25PM -0600, Dave Rolsky wrote:
> On Mon, 13 Jan 2003, Matthew Simon Cavalletto wrote:
> > Looking at the two alternatives, does the second really seem clearer?
> >
> >use DateTime;
> >my $dt = DateTime->new( 'MySQL' => $mysql_dt );
> >print $dt->to_string(
On Mon, Jan 13, 2003 at 01:00:54PM -0800, Yitzchak Scott-Thoennes wrote:
> On Mon, 13 Jan 2003 13:55:17 -0600 (CST), [EMAIL PROTECTED] wrote:
> >
> >> So, this sounds like something very high level, which shouldn't be
> >> considered part of the base object. But.. it is needed for really
> >> low-l
On Mon, Jan 13, 2003 at 01:38:36PM -0500, Rich Bowen wrote:
> On Mon, 13 Jan 2003, fglock wrote:
>
> > About "Rata Die" and "Julian Day": I'd prefer a seconds-based
> > implementation, because leap seconds would make 'seconds' be a
> > varying fraction, in a day-based calendar.
>
> Seems to me th
On Mon, Jan 13, 2003 at 01:55:17PM -0600, Dave Rolsky wrote:
> On Mon, 13 Jan 2003, Martijn van Beers wrote:
>
> > The format of the time strings and the recurrence rules are defined
> > in the iCalendar rfc (2445). This was used because the primary use
> > of Date::Set w
On Mon, Jan 13, 2003 at 01:58:59PM -0600, Dave Rolsky wrote:
> I agree that epoch is bad, because it's so limited, but it's a "standard"
> that a lot of people are familiar with, so it needs to be supported in the
> core object.
That is exactly why it _shouldn't_ be supported. it is what people us
On Sun, Jan 12, 2003 at 09:13:07AM -0500, John Peacock wrote:
> Dave Rolsky wrote:
> >
> >I'm inclined to go with ISO rather than backwards compatibility with C.
> >
>
> We really have to go with ISO because that battle has already been fought
> and won(?) in the international community. And we
On Sat, May 05, 2001 at 11:11:29PM -0600, Dan Brian wrote:
> Perhaps I'm not thinking in the same vein as others. But since the primary
> intent is a comprehensive interface to iCalendar, all effort should be
> made to conform any internal representations to the RFC fields.
That's not the primary
On Sun, May 06, 2001 at 08:41:49AM +0530, Abhijit Menon-Sen wrote:
> On 2001-05-05 21:19:26, [EMAIL PROTECTED] wrote:
> >
> > Do we want the internal representation to be a string?
>
> It's probably easiest.
>
> > [struct GDate] fits nicely inside 64 bits so you can store it as a
> > number in d
On Sat, May 05, 2001 at 02:48:25PM -0400, srl wrote:
> On 5 May 2001, Rich Bowen wrote:
> > 1) A Date::Foo object will *always* have an internal
> > representaton as an ICal string, no matter what you provide it
> > when you create it.
> Hm. I'm not so sure about this, but I guess it's the only wa
On Sat, May 05, 2001 at 01:25:30PM -0400, Rich Bowen wrote:
> I'd also propose that we write it in LaTeX, for all the usual reasons
> given for writing something in LaTeX, or in POD, for all the usual reasons for
> using POD. My preference is LaTeX, due to the greater control it gives us over
> se
On Fri, May 04, 2001 at 11:32:14AM -0400, srl wrote:
> To everyone who's here so far, hi. I'm a developer on the Reefknot
> project, as is Rich.
as am I.
I'm mostly interesting in getting a nice OO date/time module
without any of the limits of current modules (like being limited
to EPOCH date/ti
12 matches
Mail list logo
