Re: Picking up the ball
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: [...] -- It should handle fractional seconds. Based on a brief perusal of Date::ICal, I think this can be added without too much difficulty. By fractional, I hope you mean counted numbers of subsecond chunks instead of a real number representing a fraction of a second. I have no strong preference for what subsecond chunk is used. (A VMS timestamp's chunk is 100 nanosends, or 1/100 of a second, i.e. hh:mm:ss.cc) brad
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
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 calculations just a little faster when you are starting from some known date that is closer to dates that we are likely to be using. It makes the numbers that we're dealing with smaller. I think that there were other reasons. I'd have to paw through the archives. However, the actual number being stored can be changed to real MJD, and the whole thing would remain internally consistent. I think. And might end up being a little easier, since Calendrical Calculations uses that number as well. But I could be remembering wrong. Any of the other Reefknot folks remember? Inquiring minds want to know. I think this is particularly important since I was hoping to use this format as the basis for interoperability, but I'd more comfortable with a real standard for that (I suppose ICal fits the bill there, but it requires everyone to parse things out over and over). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Pilgrim, how you journey on the road you chose To find out where the winds die and where the stories go --Pilgrim (Enya - A Day Without Rain)
Re: Base object API/semantics
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 name while mon returns a number makes little
sense to me.
I propose the following:
month - 1-12
month_name - full name
month_name_abbr - abbreviated name
[ ... ]
I would like to see 1-based indexing tossed out competely. Not that it's
intuitive to use 0-indexed lists for things like dates -- it's not! But as
programmers we are used to 0-indexing and for the sake of consistency I
think we should takes this opportunity to make the date/time API conform
to the rest of computing.
I never understood why localtime returns a 0-indexed month but a 1-indexed
day of month ...
The other alternative would be to make everything 1-indexed, but that
would require remembering that DateTime differs from everything else you
use that produces a list.
- nick
Nick Tonkin {|8^)
Re: Base object API/semantics
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. Alternately, how about names like day_of_week and day_of_week_1 or something like that, so its _really_ clear what each does? Might make sense to implement a decorator that adds these later -- if people really want them. 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, see earlier question) day_name- full name day_name_abbr - abbreviated name I think this makes more sense than the Time::Piece API. The name is the full name, not the abbreviation. If you want the abbreviation, ask for it. Agreed. On Friday, January 10, 2003, at 10:24 PM, Dave Rolsky wrote: I see several possibilities: - _Nothing_ is an updater. There is no add() method on objects, only on the class (for overloading). The only way to update a date object is to replace it with a new object. - Provide a single set() method, which takes the same parameters as new(). - _All_ component accessors are updateable. So day_of_week(), day_of_year(), etc. can all be updated. A slight variation of this would be to provide set_day_of_year(), set_month(), etc. 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 provide something like this: # same as $old_date but day of month is 5 my $new_date = $old_date-clone( day = 5 ); I think that this is an excellent idea. It's a good tradeoff between flexibility and simplicity. People who just want setters will be able to fake it like this: $date = $date-clone( day = 5 ); And I like the idea of static DateTime objects. I favor exceptions myself, since I think if something is wrong, it should be considered catastrophically wrong, but I know this is a serious bone of contention. Aren't you glad I brought it up? I like exception, too, and you know that I'm a fan of Exception::Class. However, it'd probably be ideal to allow users to determine how to deal with these things, a la DBI's approach. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [mplspm]: Picking up the ball
quote from=David Wheeler
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 a
way to make this transparent to DBI. I'm not sure there's an easy
answer, though, and I'm probably just getting way too far ahead of
myself. ;-)
/quote
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(FORMAT_DATETIME);
...
}
The author of a module just have to write a date-stringification method
of his package (obviously using strftime).
Szabó, Balázs (dLux)
--
== Make love, not war ==
Re: Base object API/semantics
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 that we ever explicitly discussed it is thus. Things should be 1-based if they are 1-based in real usage. March 1 is the 1st day of the month, not the 0th. Calling March 1 day 0 will inevitably confuse everyone who did not write the module. Things should be 0 based if they are called by name in general usage. Thus, day of week should probably be 0-based. Month is a little less pleasant, but can be thought about thus. You usally use the month number as a list index. Thus, Jan should be 0 because @months is (Jan, Feb, etc) - A similar confusion exists between methods that return numbers and those that return strings. This is obviously only an issue for days and months. Exactly month/monname - abbreviated name (Jan Feb ...) fullmonth - full name mon - 1-12 _mon - 0-11 That might be a nice way to handle it if this is made abundantly clear every time one of these things is referenced in the docs. Too many date modules assume you know that things are 0 based. Or 1 based, as the case might be. -- And everyone said, If we only live, We too will go to sea in a Sieve - To the hills of the Chankly Bore! (The Jumblies, by Edward Lear)
Re: Base object API/semantics
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 provide something like this: # same as $old_date but day of month is 5 my $new_date = $old_date-clone( day = 5 ); I think that this is an excellent idea. It's a good tradeoff between flexibility and simplicity. People who just want setters will be able to fake it like this: $date = $date-clone( day = 5 ); 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. I favor exceptions myself, since I think if something is wrong, it should be considered catastrophically wrong, but I know this is a serious bone of contention. Aren't you glad I brought it up? I like exception, too, and you know that I'm a fan of Exception::Class. However, it'd probably be ideal to allow users to determine how to deal with these things, a la DBI's approach. That seems reasonable. Maybe default to throwing an object but allow a pluggable error handling subroutine reference? And maybe also a convenience option to turn off exceptions and just return undef/0 (like DBI's RaiseError). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Base object API/semantics
[ 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 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 that we ever explicitly discussed it is thus. Things should be 1-based if they are 1-based in real usage. March 1 is the 1st day of the month, not the 0th. Calling March 1 day 0 will inevitably confuse everyone who did not write the module. Things should be 0 based if they are called by name in general usage. Thus, day of week should probably be 0-based. Month is a little less pleasant, but can be thought about thus. You usally use the month number as a list index. Thus, Jan should be 0 because @months is (Jan, Feb, etc) This is a really good way to look at it. I think this can go into the module docs as is, along with an explicit list of which number-returning methods return 0-based, and which 1-based. On second thought, I'm inclined to make an exception for month number, just because we're so used to writing things like 2002-12-06. Nobody ever writes 2002-00-02 or something like that! -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Base object API/semantics
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 believe. The reasoning here, although I don't know that we ever explicitly discussed it is thus. Things should be 1-based if they are 1-based in real usage. March 1 is the 1st day of the month, not the 0th. Calling March 1 day 0 will inevitably confuse everyone who did not write the module. Things should be 0 based if they are called by name in general usage. Thus, day of week should probably be 0-based. Month is a little less pleasant, but can be thought about thus. You usally use the month number as a list index. Thus, Jan should be 0 because @months is (Jan, Feb, etc) This is a really good way to look at it. I think this can go into the module docs as is, along with an explicit list of which number-returning methods return 0-based, and which 1-based. month/monname - abbreviated name (Jan Feb ...) fullmonth - full name mon - 1-12 _mon - 0-11 That might be a nice way to handle it if this is made abundantly clear every time one of these things is referenced in the docs. Too many date modules assume you know that things are 0 based. Or 1 based, as the case might be. This is actually how Time::Piece documents all its methods. For DateTime.pm, I'll stick this sort of thing in the synopsis, so people see it right away. That way it's quick to get at when you forget ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [mplspm]: Picking up the ball
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(FORMAT_DATETIME);
...
}
The author of a module just have to write a date-stringification method
of his package (obviously using strftime).
Yes, a similar approach occurred to me. We'll have to look at this when
the time comes, for sure.
One issue to keep in mind: I don't think that DBI will stringify by
default.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Base object API/semantics
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 other ought to chime in here. Others? That seems reasonable. Maybe default to throwing an object but allow a pluggable error handling subroutine reference? And maybe also a convenience option to turn off exceptions and just return undef/0 (like DBI's RaiseError). Yes, that's what I was thinking, along with a PrintError, just for those who actually like warnings. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
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 conclusion that we came to. Indeed, we changed the internals at least twice, with no change to the API. -- Rich Bowen - [EMAIL PROTECTED] http://kenya.rcbowen.com/
Re: Base object API/semantics
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 names like day_of_week and day_of_week_1 or
something like that, so its _really_ clear what each does?
1. Declare one standard, but don't make March 1 be day-of-month 0, and
I'd prefer that March wasn't month 02. That just guarantees the extra
bytes in everyone's code, somewhere between calculation and output...
2003-00-10 what day is that? Today?? No, today should be (2003, 01,
11) at all times.
2002-12 is January 2003 ?!!! No, 2002-13 would be January 2003.
Even though I'm totally accustomed to 0-based indexing of months a la
localtime, it always reminds me of someone's email signature that says:
There are 10 kinds of people in the world: those who get binary and
those who don't.
A good API shouldn't employ the equivalent of an inside joke.
Having a way to coerce the non-standard would also be good; but I'd
caution that someone might mistake 'day_of_week_1' as having something
to do with 'week 1', i.e., 'the first week'.
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, see earlier question)
day_name- full name
day_name_abbr - abbreviated name
I think this makes more sense than the Time::Piece API. The name is
the
full name, not the abbreviation. If you want the abbreviation, ask for
it.
2. Yes. All good. How about also using this convention for a consistent
way to indicate numerical vs. string?
As in:
Anything with _name - string
Anything with _of - numerical
Anything plain- numerical (does this work? day, month,
year, ...)
At times for clarity I also use:
Anything with _num - numerical
Anything with _str - string
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 something like
'Wednesdayth'.
OTOH, this would be efficient:
day_ord- '5th'
day_ord_str- 'Fifth'
Not saying here that DateTime.pm should provide ordinals, but just that
it would be great to extend its method-naming scheme downstream, and an
unambiguous distinction between string and numerical returns would
help...
3. I vote for static DateTime objects. I think that makes it easier to
keep track of complicated namespaces, re-entries, etc., anyway.
4. For setters, I'm happy with usages like
$new_date = $date-clone( day = 5 );
and its implied
$date = $date-clone( day = 5 );
Thanks, Dave.
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: Base object API/semantics
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 it's like that except for day of week. Hmm, I will ponder this some more. Nah, Matthew is right, I think Just do it. The only time you shouldn't do it is if we override localtime and want to stringify it like Time::Piece does. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Base object API/semantics
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 today Elevenday or something ;) Could we use the term weekday instead of day_of_week, or does that seem like we're opposing it to weekend? (I think it's safe to s/name_abbr/abbr/ without confusing users.) Actually, I already did that in the code ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Base object API/semantics
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 you call today Elevenday or something ;) I wouldn't rule that out when it comes to other calendars. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
