I'm glad this is starting up again. We here in VMS land have very
nice date and time functionality built into the OS; I want to keep
an eye on the direction this takes just to make sure it doesn't
become drastically incompatible with VMS timestamps.
Just one comment for now:
Dave Rolsky wrote:
On Sat, 11 Jan 2003, Dave Rolsky wrote:
> No, this has nothing to do with Mr. Dominus.
>
> Rich, can you explain the pseudo-mjd system that Date::ICal uses for its
> internals? And why didn't you you use real MJD?
It is MJD + an offset (or - an offset, as the case may be). It makes the
calculati
On Fri, 10 Jan 2003, Dave Rolsky wrote:
> Can we simply declare 0-based as the standard for day of week and day of
> year, and 1-based for day of month, month of year, and week of year.
> FWIW, that's what Date::ICal already had implemented, I believe.
> [ ... ]
> The fact that month returns a nam
On Friday, January 10, 2003, at 09:52 PM, Dave Rolsky wrote:
Can we simply declare 0-based as the standard for day of week and day
of
year, and 1-based for day of month, month of year, and week of year.
FWIW, that's what Date::ICal already had implemented, I believe.
Sounds good to me.
Alter
The problem with that is that then the particular $sth would have to
have the necessary column bound explicitly:
$sth->bind_param($param_num, $bind_value,
{ type => DATE_TIME });
While that'd do-able, it's annoying. I'd rather see if there wasn't
On Fri, 10 Jan 2003, Dave Rolsky wrote:
> Can we simply declare 0-based as the standard for day of week and day of
> year, and 1-based for day of month, month of year, and week of year.
> FWIW, that's what Date::ICal already had implemented, I believe.
The reasoning here, although I don't know th
On Sat, 11 Jan 2003, David Wheeler wrote:
> > The first option has the advantage of greatly simplifying the
> > internals. Once you calculate the julian day and seconds for an
> > object, it just never changes. The disadvantage is that the API may
> > seem odd to some folks. But we could still pr
[ Soon the list archives will consistent entirely of me responding to
myself ... ]
On Sat, 11 Jan 2003, Dave Rolsky wrote:
> On Sat, 11 Jan 2003, Rich Bowen wrote:
>
> > On Fri, 10 Jan 2003, Dave Rolsky wrote:
> >
> > > Can we simply declare 0-based as the standard for day of week and day of
> >
On Sat, 11 Jan 2003, Rich Bowen wrote:
> On Fri, 10 Jan 2003, Dave Rolsky wrote:
>
> > Can we simply declare 0-based as the standard for day of week and day of
> > year, and 1-based for day of month, month of year, and week of year.
> > FWIW, that's what Date::ICal already had implemented, I belie
On Saturday, January 11, 2003, at 11:08 AM, dLux wrote:
I imagined the following stringification method:
use overload '""'=> "as_string";
sub as_string {
my ($self) = @_;
my ($package) = caller;
no strict refs;
return $package->FORMAT_DATETIME($self)
if $package->can("FORM
On Saturday, January 11, 2003, at 12:38 PM, Dave Rolsky wrote:
And I like the idea of static DateTime objects.
I think it's appealing for me in implementing it, and it's very
logical,
but is it practical? I'm not so sure about that.
We'll have to see. It'd work for me, in general, but oth
On Sat, 11 Jan 2003, Dave Rolsky wrote:
> You know, on reflection, I don't think the internals matter _at all_
> (well, they need to work, but you already took care of that ;) What
> matters is that we can return a _standard_ value for the use of other
> calendar implementers.
Yes, that is the c
On Friday, January 10, 2003, at 09:52 PM, Dave Rolsky wrote:
Can we simply declare 0-based as the standard for day of week and day
of
year, and 1-based for day of month, month of year, and week of year.
FWIW, that's what Date::ICal already had implemented, I believe.
Alternately, how about name
On Saturday, January 11, 2003, at 03:49 PM, Dave Rolsky wrote:
On Sat, 11 Jan 2003, Rich Bowen wrote:
On Fri, 10 Jan 2003, Dave Rolsky wrote:
Can we simply declare 0-based as the standard for day of week and
day of year, and 1-based for day of month, month of year, and week
of year.
Things
On Sat, 11 Jan 2003, Matthew Simon Cavalletto wrote:
> > Nobody ever writes 2002-00-02 or something like that!
>
> Nobody ever writes "the 0th day of the week" either!
Damn, that's a good point. And this could lead to the very simple rule
of:
All _date_ numbers are 1-based. All _time_ numbers
On Saturday, January 11, 2003, at 03:14 PM, Dave Rolsky wrote:
Nobody ever writes "the 0th day of the week" either!
Damn, that's a good point. And this could lead to the very simple rule
of:
All _date_ numbers are 1-based. All _time_ numbers are 0-based. Ooh,
that's appealing.
Right now i
On Sat, 11 Jan 2003, Bruce Van Allen wrote:
> I need _num at times when _name doesn't quite make sense for its
> converse:
>day_ord- e.g., 'Fifth' [the proper ('full') ordinal]
>day_ord_num- e.g., '5th' [really an abbreviation]
> because day_ord_name or day_name_ord might imply
On Friday, January 10, 2003, at 09:52 PM, Dave Rolsky wrote:
I propose the following:
month - 1-12
month_name - full name
month_name_abbr - abbreviated name
day - _day of month_ (makes sense in context of year() and
month() methods)
day_of_week - 0-6 (or 1-7, se
On Sat, 11 Jan 2003, Matthew Simon Cavalletto wrote:
> Hmm -- that looks like trouble; month_name() is the written version of
> month(), but day_name() is the written version of day_of_week() rather
> than of day().
But days only have names in terms of their position in the week. Unless
you call
On Saturday, January 11, 2003, at 03:24 PM, Dave Rolsky wrote:
Hmm -- that looks like trouble; month_name() is the written version of
month(), but day_name() is the written version of day_of_week() rather
than of day().
But days only have names in terms of their position in the week.
Unless
20 matches
Mail list logo
