Re: Which DOW is day #1?
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 have already committed to ignore localtime's perversions when required... iCalendar (rfc 2445) specifies a WKST property for recurrence rules to let you define your own start of the (work) week. The default for this is Monday. Martijn
Re: Which DOW is day #1?
On Sunday, January 12, 2003, at 11:15 AM, John Peacock wrote: A lot of the 0-based vs 1-based arguments should be resolved simply by having our interface design in place. Programmers will be less inclined to have to look up some 0-based array when the API we provide does it for them, i.e. month[$date-month_num] vs. $date-month both return January I think that this will be resolved by: month[$date-month_0] vs. $date-month both return January David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Which DOW is day #1?
On Sunday, January 12, 2003, at 10:48 AM, Rich Bowen wrote: On Sun, 12 Jan 2003, John Peacock wrote: We really have to go with ISO because that battle has already been fought and won(?) in the international community. Well, I was going to say the following: This is not about either ISO standard or backward compatibility with C, but about common usage. People think of Sunday as the first day, and so we should stick with that, so as not to confuse people. However, based on your comment, I'm not sure if that is the case. This is a classic localization problem, with the convention varying from one place and time to another. I've seen a number of indications that many, perhaps most, Europeans consider the week to start on Monday, and a quick Google search turned up more anecdotal support for this theory, ex: Many British calendars and diaries use Monday as the start of the week; but some still use Sunday. (http://www.merlyn.demon.co.uk/weekinfo.htm) Another source clarifies that starting on Sunday is in fact the original pattern, and that counting from Monday is a later development of European cultures, especially Protestant and German-speaking ones. (http://www.friesian.com/week.htm) Personally, I've always preferred calendar weeks that start on Monday, partly for the onomatopoeia (mONEday, TWOsday, 3ednesday, FOURsday, FrIVEsday, ...), and partly because it synched up with the school-day/work-day cycle. Synchronization to the work week is also useful in some kinds of business contexts -- if you're scheduling weekday shifts, it's more convenient for your work days to run from 1-5 than from 2-6 -- and I believe the ISO week-numbering work is based on existing practices in the manufacturing industry. Some desktop calendar software allows you to switch the display to Monday weeks, and many business-week planning calendars also start on Monday. In a sense, one would like to be able to treat this as a locale issue, so that a user could specify the convention used in their setting, in the same way that they can select the language used. (I'm in Germany, give me German day names and ISO weeks.) A simpler solution would be to support multiple interfaces: ($year, $week_num, $week_day) = $dt-greg_week(); ($year, $week_num, $week_day) = $dt-iso_week(); Callers could choose to request whichever number they wanted: - $dt-iso_week_day - 1..7 starting with Monday - $dt-iso_week_day_0 - 0..6 starting with Monday - $dt-greg_week_day - 1..7 starting with Sunday - $dt-greg_week_day_0- 0..6 starting with Sunday -Simon
Re: Discarding some fifteen functions/methods in favour of an enhanced strftime
On January 12, 2003, at 07:29 AM, Antonios Christofides wrote:
Get rid of the methods/functions returning year, month, day of week,
day of month, day of year, hour, minute, second, week of year, week of
month, whatever, and use an enhanced strftime [...]
This enhanced strftime is a very nice interface, in line with Perl
idiom, and should be easy to add to the code, but I think eliminating
the standalone methods is going to sharply reduce user acceptance of
the new module.
# Change the hour to 17
datetime_object - strptime('%Y-%m-%d %H:%M:%S',
datetime_object - strftime('%Y', '%m', '%d', '17', '%M',
%S'));
Ick. That's clearly not as nice as just saying $dt-hour(17).
-Simon
Re: Base object API/semantics
On Sun, 12 Jan 2003, David Wheeler wrote: On Saturday, January 11, 2003, at 09:56 PM, Nick Tonkin wrote: Except that there's already one thing different from everything else in most existing implementations: the first day of the month starts with 1, not 0. See localtime. Hmm, but isn't that the value rather than array index? In the case of objects, they're all values. That's not what I meant. I mean that when a caller asks for day of month they expect the final value that a human needs, rather than an index for counting. - nick
Re: Which DOW is day #1?
On Sun, 12 Jan 2003, David Wheeler wrote: On Sunday, January 12, 2003, at 11:15 AM, John Peacock wrote: A lot of the 0-based vs 1-based arguments should be resolved simply by having our interface design in place. Programmers will be less inclined to have to look up some 0-based array when the API we provide does it for them, i.e. month[$date-month_num] vs. $date-month both return January I think that this will be resolved by: month[$date-month_0] vs. $date-month both return January Make that: $month[ $date-month_0 ] vs. $date-month_name $date-month returns a 1-based numbers $date-month_0 a 0-based named $date-month_name returns a name based on the DateTime::Language module the $date object is holding onto. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Discarding some fifteen functions/methods in favour of an enhanced strftime
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote: Ick. That's clearly not as nice as just saying $dt-hour(17). Whether this method is an updater is an entirely different can of worms ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Base object API/semantics
On Sun, 12 Jan 2003, David Wheeler wrote: So keep the base class named DateTime and provide a single implementation class module DateTime::Gregorian, which is the default unless you ask for something else. The advantage of this is we have to work through the interface issues required to do DateTime::SomethingElse right away, since we are already implementing another module from the get go. I like it... Yes, and I third this motion. Uh, could someone summarize this thread, and the motion at hand, keeping in mind that calendar-specific modules will be DateTime::Calendar::X, not DateTime::X? I've kind of lost track of what's being proposed. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Base object API/semantics
On Sun, 12 Jan 2003, dLux wrote: # same as $old_date but day of month is 5 my $new_date = $old_date-clone( day = 5 ); I used this in Class::Date, because of the object-semantics of perl: If an object is referenced from more than one place, then it silently changes all date objects. But that might actually be a good thing. I guess it depends on whether we expect people to understand the difference between references and values and how that works with objects, I suppose. I tend to think that when I pass an object to a function/method, or store it in a data structure, that it's the _same_ object at all times. This is in fact correct. Other people, however, may lose track of that, and think it's different, leading to weird surprises when $datetime and $dates[27] _both_ change when $datetime is updated. I think throwing an object is better. I don't really like parsing error messages to determine what error is happened. Just think about internationalization. I think we've agreed on DBI-like flexible behavior (return undef, die, or call a user-defined callback). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Static objects with dynamic wrappers?
On Sunday, January 12, 2003, at 05:27 PM, Dave Rolsky wrote: On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote: Ick. That's clearly not as nice as just saying $dt-hour(17). Whether this method is an updater is an entirely different can of worms ;) If not, it'd presumably be easy to stick an updating decorator in front of it, using the same type of structure as in the dynamic wrapper for static objects class I proposed earlier. $dth-hour(17); # Really calls $$dth-clone( hour = 17 ) or equivalent # internal gymnastics, and then stores the resulting object. -Simon
Re: Base object API/semantics
On Sunday, January 12, 2003, at 02:33 PM, Dave Rolsky wrote: I think throwing an object is better. I don't really like parsing error messages to determine what error is happened. Just think about internationalization. I think we've agreed on DBI-like flexible behavior (return undef, die, or call a user-defined callback). And die with an exception object as the default, yes? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Static objects with dynamic wrappers?
On Sunday, January 12, 2003, at 02:36 PM, Matthew Simon Cavalletto wrote: If not, it'd presumably be easy to stick an updating decorator in front of it, using the same type of structure as in the dynamic wrapper for static objects class I proposed earlier. $dth-hour(17); # Really calls $$dth-clone( hour = 17 ) or equivalent # internal gymnastics, and then stores the resulting object. Yes, although if someone expects the object reference to be the same, they'll get a rude surprise. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Base object API/semantics
On Sun, 12 Jan 2003, David Wheeler wrote: John and I liked the former option, though you expressed your opposition to it yesterday. The advantage is that the interface is exactly the same regardless of calendaring system, and we deal with the issues of allowing DateTime to return different calendar types right now, up front. Does that help? Yes, it does. Too many messages these past few days. My brain hurts. Anyway, I really don't see the point of this. Other calendaring systems will have different APIs, that may or may not resemble the API that's most appropriate for the Gregorian calendar. For example, see Rich Bowen's Date::Discordian on CPAN. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
DateTime Namespace (Was Re: Base object API/semantics)
On Sunday, January 12, 2003, at 05:55 PM, Dave Rolsky wrote: On Sun, 12 Jan 2003, David Wheeler wrote: The advantage is that the interface is exactly the same regardless of calendaring system, and we deal with the issues of allowing DateTime to return different calendar types right now, up front. [...] I really don't see the point of this. Other calendaring systems will have different APIs, that may or may not resemble the API that's most appropriate for the Gregorian calendar. For example, see Rich Bowen's Date::Discordian on CPAN. But in fact the Discordian calendar is a lot like the Gregorian calendar -- they have years, months (seasons), and days. Likewise the Hebrew calendar, and the Mayan. (The overlapping Tzolkin and Haab cycles in the Mayan calendar are reminiscent of the month and week cycles in the Gregorian calendar.) If the DateTime framework is sufficiently open and inviting, we have the opportunity to encourage convergence of modules supporting those calendars -- obviously, there'll be portions of the API that differ from calendar to calendar, but we can still share a common core interface of methods like from/to_epoch, from/to_julian, strftime, strptime, etc. -Simon
Picking up the ball...or reinventing the wheel?
I need to find more time to read through the flood of messages...but
wanted to mention right away that things look to be going astray.
Apologies if it is not so.
What's the goal here? If it is creating a base class for date/time
modules to standardize on, that won't work. I don't think the authors
of the existing modules are interested. That way only leads to the
creation of Date::Yet::Another::Module.
If it is creating a module to provide some glue between existing
modules, great--but make sure that's the focus. Does that need to be
more complicated than:
$from_object = Date::ICal-new( ical = '19971024T12' );
Date::Glue::-make_a('Date::Calc::Object', $from_object)
where Date::Glue understands the get/set API of as many as possible of
the OO date modules out there?
Another goal I see as worthwhile would be a non-partisan document
comparing the strengths and weaknesses of the existing modules, with a
link to it from the date and time categories on CPAN.
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
On Sat, 11 Jan 2003 16:44:37 -0500 (EST), [EMAIL PROTECTED] wrote: 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. Date::ICal uses what Calendrical Calculations uses (that they call Rata Die, fixed date). They are days on or after Jan 1 of year 1 (Gregorian). This different from MJD. I'd like to see Date::ICal switch to using rd to describe them instead of jd in some places and julian in others. The greg2jd and jd2greg functions should work for any R.D. between minint and maxint inclusive. This gives a range of 11.75+ million years with 32 bit ints and 50 quadrillion years with 64 bit ints. The only other function that really needs to access the internal format is day_of_week. greg2jd is also supposed to return correctly normalized results for any integer values given (e.g. with year -1200, month 1, and day 21, you should get the R.D. 2 billion days after the start of year -1200.). The subs greg2jd and jd2greg and the tests in 09greg.t are are in the public domain. They are based on ideas from the first edition of Calendrical Calculations (especially the Cycles of Years section) but use no actual algorithms from it (which may be under copyright and/or patent protection--though I think Rich Bowen does have an arrangement with the authors for some of his work.) They do resemble the alternate Gregorian functions in the second edition.
Re: DateTime Namespace
On Sunday, January 12, 2003, at 05:30 PM, Dave Rolsky wrote: [...] keeping in mind that calendar-specific modules will be DateTime::Calendar::X, not DateTime::X [...] I think the make Gregorian explicit line of reasoning actually supports moving the various calendars up to second-level namespaces, and filing the various Events and Algorithms at a level below those. Here's how the multiple-calendar namespace might look: # General-purpose gateway and temporal geometry DateTime -- Factory methods and class lookup DateTime::Calendar (POD only?) -- Common interface for calendars DateTime::Delta-- Difference between two points DateTime::Set -- A collection of points DateTime::Span -- A period between two points DateTime::SpanSet -- A collection of spans # Our core calendar DateTime::Gregorian-- Our primary, modern calendar DateTime::Gregorian::Language -- Internationalization DateTime::Gregorian::RichParser - Based on Date::Manip et al. DateTime::Timezone -- Interface to global offset data The main distribution would presumably only include these basic gateway/geometry modules and the Gregorian calendar, but it leaves room for a proliferation of interoperating modules: # Calendar algorithms, also expressable as infinite sets DateTime::Gregorian::LeapYear -- Was DateTime::Algorithm::Leapyear DateTime::Gregorian::Christmas -- Was DateTime::Event::Christmas DateTime::Gregorian::Easter-- Not written yet # Regional variations of the Gregorian calendar get namespaces DateTime::EasternOrthodox::Christmas DateTime::US::FourthofJuly -- Was DateTime::Event::FourthofJuly DateTime::Solar::Equinox -- Find equinox and solstice dates # Other calendars, with associated algorithms and events DateTime::Chinese -- Not written yet DateTime::Chinese::YearAnimal -- Was Date::Chinese DateTime::Discordian -- Was Date::Discordian DateTime::Discordian::SaintDays -- Not written yet DateTime::Hebrew -- Was Locale::Hebrew::Calendar DateTime::Hebrew::Passover -- Was DateTime::Algorithm::Passover DateTime::Mayan-- Was Date::Maya DateTime::Roman-- Not written yet # Specialized implementations might get their own namespaces DateTime::Epoch::Posix -- Just a blessed time() value DateTime::Epoch::HiRes -- Based on Time::HiRes DateTime::Epoch::TAI64 -- Based on Time::TAI64 DateTime::Epoch::TAI64N-- Based on Time::TAI64N # Other generic geometry or utility modules filed at top level DateTime::Handle::SelfUpdate-- Wrapper to allow $dt-hour(17) DateTime::Sequence -- Ordered set DateTime::SpanSet::SparseMatrix -- Some kind of efficient storage? Does this system seem confusing? If you didn't know what Gregorian meant, you might feel kind of lost, but otherwise I hope people will find it reasonably intuitive. Does the organization seem too broad, rather than deep? I'm trying to avoid asking people to put separately-distributed modules below the third level, to avoid 40-character monstrosities like DateTime::Calendar::Chinese::YearAnimal and DateTime-Calendar-Hebrew-Passover-1.0.tar.gz. 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 going to be second-class citizens. -Simon
Re: Picking up the ball...or reinventing the wheel?
On Sun, 12 Jan 2003, Yitzchak Scott-Thoennes wrote: Another goal I see as worthwhile would be a non-partisan document comparing the strengths and weaknesses of the existing modules, with a link to it from the date and time categories on CPAN. This has been one of my goals for many moons. In fact, it's one of the things I talked about in one of the first posts to this mailing list. And I would still like to do that. -- Rich Bowen - [EMAIL PROTECTED] ... and another brother out of his mind, and another brother out at New York (not the same, though it might appear so) Somebody's Luggage (Charles Dickens)
Re: Which DOW is day #1?
On Sun, 12 Jan 2003, Rich Bowen wrote:
On Sun, 12 Jan 2003, Nick Tonkin wrote:
Funny how the Christian point of view is that Sunday is the first day of
the week, when God rested on the seventh day after working to make the
world. Seventh which is Sunday for Christians .. (and Saturday which is
seventh for Jews, so for them Sunday _is_ the first day).
I would greatly prefer it if we not indulge in implied or actual
criticizm of various religions, if it's all the same to you. Your
comments here show that you're unaware of the Christian point of view,
which makes a very clear distinction between the seventh day, on which
God rested, and Sunday, which is a celebration of the resurrection of
Jesus. The seventh day, the Sabbath, is Saturday in the Jewish
tradition. Sunday has been celebrated in the Christian church,
since the first Century AD, in commeration of the resurrection,
not as equated to the Sabbath. That confusion may exist in certain
protestant denominations, but is not the understanding of the larger
Christian Church.
Really the only reason for making this clarification at all, and not
entirely dropping the religious pursuit of this discussion, is that
religion is critical in many of the most interesting calendars on this
planet, and one cannot fully appreciate the history and nuances of any
of these calendars, notwithstanding the ISO, without a correct
understanding of the religious communities that stand behind them, even
if you view them merely as historical curiosities, rather than as
transcendent truths.
So, I, for one, and I'm sure many others, would appreciate it if
everyone restrain from slights, implied or actual, on religions that
will, of necessity, arise in calendrical discussion.
Thanks.
Rich
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. But my point was simply that cultural and
religious traditions that may not make sense to the programmer are often
very important. Similar to what you stated above. You took offense where
one was neither intended nor made.
- nick
Nick Tonkin {|8^)
Re: Base object API/semantics
On Sun, 12 Jan 2003, Dave Rolsky wrote:
On Sun, 12 Jan 2003, David Wheeler wrote:
My apologies for misunderstanding. What I meant was that, yes, the
1-starting month numbers are values, rather than array indices.
However, nowhere that I know if is there a situation in which month
numbers are returned 0-indexed, that is, as array indices.
You're wrong, you do know exactly such a situation. Perl's localtime
(which is based on C's localtime) returns exactly this (0-11). Days of
week are 0-6 (Sun-Sat), and day of year is 0-364.
All of which are values that you would use in a further calculation of
some kind, rather than on an interface. Unlike date of month, which is
consumed by humans directly, and as noted _is_ 1-indexed.
But this interface seems rather outdated and borderline pathological,
since it also returns year as number of years since 1900. So it hardly is
the basis of a good _generally useful_ datetime API!
Spurious logic. No one's claiming it's that. But if it has good features
or design elements they should be considered on their own merit.
But overall, my point is that, with true DateTime objects with good
localization support, there will be very little need for array indexes
for months, day of week, or even day of month.
Here's where I think you're wrong. I think it's fantasy to imagine that
the new DateTime interface will be so comprehensive and so perfect and so
widely accpeted and implemented that the only way anyone will ever use a
DateTime object is to produce data that will be output to the user as is.
Reality is that while a good interface will go a long way towards that
goal, there will be a lot of users of the objects that will expect
zero-indexed values for a lot of fields for a variety of reasons. And if
you want the module to be really useful you need it to be plug and
play. That's why I've argued for the 1-indexed data to _not_ be the
default; the only users of that are going to actual humans and UIs and
they are thus well able to turn a switch on. Machines are more dense and
will expect what they've always been fed. I just think it's naive to
believe that there will be very little need for array indexes in the
real world.
So it makes sense to
make the 1-based enumerations the default for these things, and provide
*_0 methods for those who still want array index-type numbers.
Yep.
Let's end this particular discussion (0-based vs. 1-based). I'm happy
with the 1-based API as default, with *_0 methods for when that is needed.
Let the record show that not everyone is :)
- nick
Nick Tonkin {|8^)
Re: Base object API/semantics
On Sun, 12 Jan 2003, Nick Tonkin wrote: Reality is that while a good interface will go a long way towards that goal, there will be a lot of users of the objects that will expect zero-indexed values for a lot of fields for a variety of reasons. And if you want the module to be really useful you need it to be plug and play. That's why I've argued for the 1-indexed data to _not_ be the default; the only users of that are going to actual humans and UIs and they are thus well able to turn a switch on. Machines are more dense and will expect what they've always been fed. I just think it's naive to believe that there will be very little need for array indexes in the real world. And that's why we have a whole set of foo_0 methods. Let the record show that not everyone is :) Duly noted. Let's leave this particular debate now. There's lots more to be done. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Base object API/semantics
On Sun, 12 Jan 2003, David Wheeler wrote: On Sunday, January 12, 2003, at 02:33 PM, Dave Rolsky wrote: I think throwing an object is better. I don't really like parsing error messages to determine what error is happened. Just think about internationalization. I think we've agreed on DBI-like flexible behavior (return undef, die, or call a user-defined callback). And die with an exception object as the default, yes? That's what I'm thinking, but I wanted to hear any major objections to this plan before its implemented. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Date::ICal's pseudo-mjd versus real MJD - Rich?
On Sun, 12 Jan 2003, Yitzchak Scott-Thoennes wrote: Date::ICal uses what Calendrical Calculations uses (that they call Rata Die, fixed date). They are days on or after Jan 1 of year 1 (Gregorian). This different from MJD. I'd like to see Date::ICal switch to using rd to describe them instead of jd in some places and julian in others. Aha. I just ordered this book, and it should be here next week. So this particular calculation is documented somewhere outside Date::ICal? That is a good thing. As to switching the internals, that sounds like a good idea, since it's misleading as is. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
