On 21/11/2007, Scott Wheeler <wheeler@kde.org> wrote:

But let's say that you want your ChucKoo clock to let you sleep in on
Saturday.  Well, then you need your date / time class to be able to
report the day of the week.  Or if you want to say, "How much time is
there between now and tomorrow at noon?"  You need to have API support
for adding and subtracting time.


I'm sure this is very naive again, but we do have lots of support for adding and subtracting time. We have both "time" and "duration" as datatypes and day, hour, minute,etc, etc, etc as constants ready made.

If we'd have even -say- a function that would report the amount of samples that have passed since newyear 2000 in our timezone it would be quite straightforward to discover the amount of time until "tomorow at noon".

The hard bits -as I see it- would be that daylight saving time is variable per country and that within countries this changes as well from year to year (for reasons I don't quite understand like much of how government works...). Just now I read that people are debating whether we should even observe leap-seconds at all. To me it seems quite clear that we will never be able to make a function that can predict the whims of politicians in every country ChucK may be used in with regard to how we will look at the clock and calendar in the future. I'm not even sure if computers in Israel (which I assume observes the Jewish calender) or China (which I would guess observes the Chinese year) use the same calender as my European computers do.

As I see it right now these are cultural questions which don't need to matter all that much from a ChucKian point of view. If we'd like to establish the time from a ChucKian point of view I think it would do to know the amount of time that has passed since some known point in time (the birth of the universe, ChucK, Unix or one's favourite religious person, etc) and to know how the calender we'd like to observe works. We already have enough ways to deal with time to take it from there on.

Admittedly that would be a bit abstract at the expense of ease of use for most people most of the time but I don't think that a API to reason about time as such is the bottle-neck here.


Ok, now that I think about it there are some quite amusing questions. For example, if we would have such a built in calender/clock, would we be able to use this?;

if (day % 24::hour) //check to see if we need to adjust for daylight savings time today

That would be quite funny.
:¬)

Kas.