On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote:
# Our core calendar
DateTime::Gregorian-- Our primary, modern calendar
DateTime::Gregorian::Language -- Internationalization
DateTime::Gregorian::RichParser - Based on Date::Manip et al.
Except as you point out,
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote:
I was originally unenthusiastic about static date-time objects, but
then I realized that it'd be reasonably straightforward to build a
variable wrapper object, which could then be used to hold a series of
static objects:
Ack, too much
On Sun, Jan 12, 2003 at 08:08:17PM -0500, Matthew Simon Cavalletto wrote:
Does it invite others to add their own modules? Pushing the main
implementation down a level might seem like a meaningless detail, but
my hope is that it helps to signal to other module authors that they're
not
On Mon, 13 Jan 2003, Jean Forget wrote:
Well, it is not *that* simple. In addition to creating a new
calendar, Fabre d'Eglantine and Romme changed the duration of
the hour, minute and second, so each day would be split into
10 hours, each hour into 100 minutes and each minute into 100
On Sun, 12 Jan 2003, Nick Tonkin wrote:
You completely misunderstood my point, Rich. I was not implying any slight
whatsoever. I continue to disagree with your opinion about the first day
of the week in the Christian tenet(s), about which I know a good deal more
than you evidently think.
I
On Mon, 13 Jan 2003, Dave Rolsky wrote:
from/to_julian (or rata_die, I think), definitely, since without that it's
not interoperable with anything else.
The more I read Calendrical Calculations, the more I like the rata_die
concept, rather than the julian day concept. They are, of course, the
On Mon, 13 Jan 2003, Rich Bowen wrote:
It's an interesting point in this case, with this being one of the very
few calendars that changes how time is handled. However, since the
purpose of the module in question is conversion between Gregorian and
French Revolutionary, I would expect that it
DateTime::new sub is
over 100 lines long... The overhead of one more method call seems like
It's over 100 lines cause it needs refactoring. That's on my todo list.
my $dt = DateTime-new( ICal = '20030113' );
# Causes DateTime to load the ICal format module and request that
# it parse
On Mon, 13 Jan 2003, Dave Rolsky wrote:
On Mon, 13 Jan 2003, Rich Bowen wrote:
So the internals would become ... what exactly? Right now, there are two
integers stored - the julian day, which is not actually the julian
day, and the seconds, which is seconds since midnight (although I tend
On Mon, 13 Jan 2003, Rich Bowen wrote:
We had discussed, at some length, over on Reefknot, about making these
things storable, and that's an ongoing consideration. Putting an object
in the object is all well and good, as long as there is a simple
strinification that we can do, and store in a
On Mon, 13 Jan 2003, Martijn van Beers wrote:
But nothing fancy, just a few formats should be supported in the
base class, including epoch time, ICal, and maybe ISO 8601.
I wouldn't call epoch arguments parsing, but I would really like it if
this wasn't in the base class. Making people go
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-level operations, like -add(). For example:
19700328T233000 + 4 hours = ??
You'd think
Continuing the discussion with Rich Bowen (Mon, 13 Jan 2003 06:28:14 -0500 (EST))
On Mon, 13 Jan 2003, Jean Forget wrote:
Well, it is not *that* simple. In addition to creating a new
calendar, Fabre d'Eglantine and Romme changed the duration of
the hour, minute and second, so each day would
Monday!
How exciting. I figured I might as well just pick something, and so I
picked Monday. There were a lot of excellent candidates, and Friday's
performance was excellent, but overall Monday best exemplified the
qualities that I look for in a week-starter.
-dave
/*===
On Mon, 13 Jan 2003, Martijn van Beers wrote:
gives:
[19700329T02..19701025T03],
[19710328T02..19711031T03],
[19720326T02..19721030T03]
The format of the time strings and the recurrence rules are defined
in the iCalendar rfc (2445). This was used
We need to handle them. Flavio claims that using floating point seconds
makes this easier.
I have an idea on how to handle it without that, but I'd like to hear
Flavio's idea. And if anyone else has any good ideas or pointers to known
implementations (I know libtai64 handles it, for one),
On Mon, 13 Jan 2003, Martijn van Beers wrote:
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
17 matches
Mail list logo
