Hi,
In keeping with the spirit of posing challenging (interesting?) questions...
Expressing (calendar) *time* to the user presents a dilemma. Most devices that are aware of calendar time also include provisions for *setting* (i.e., altering!) the time. And, there are few restrictions as to how and when the user can alter that time setting!
However, in terms of the machine's viewpoint, time is (must be!) a monotonically increasing function. The "time setting" is just an arbitrary parameter established for the convenience of the user -- it bears no relationship to "real" time.
But, when the user expresses a temporal event, he does so in *some* context (this will prove to be the essence of this question). Yet, the machine may be operating in a *different* context -- or, simply impervious to the subtlety of the user's viewpoint!
For example, if the user schedules an "appointment" for "3:00PM Tuesday", chances are, he *means* "3:00PM" in some absolute sense. OTOH, if it is 2:00PM presently and he wants to do something "in about an hour", he
*says* "3:00PM" but really intends that to be "60 minutes from NOW".The problem lies in the fact that the time associated with "NOW" is always vulnerable to the user (re)setting the (time-of-day) clock! So, if he happens to realize he needs to set the clock forward one hour (Springtime DST processing) NOW has suddenly *become* 3:00PM -- time for that event that he scheduled for "in about an hour".
I've "solved" this problem by never letting the user change the machine's notion of "current time". Rather, he can determine the *bias* that should be applied to the time that the machine *reports* to him, but not the time itself.
(this eliminates a whole class of potential problems that can occur with the user altering the time setting wantonly -- at least the machine will be sane in how it deals with those temporally ordered events)
I log "time changes" (i.e., "bias adjustments") so I can translate the "system time" into whatever "local time" was in effect at the time. E.g., I can tell the user that he changed the "clock" at 2:34PM on January 13th to read "3:12PM", instead. And, that at 3:13PM (exactly *one* minute later!) he changed it to read "3:00PM" (for whatever reason).
From the machine's point of view, this is a boon. The machine's notion of time remains unaltered. It doesn't see those time changes as happening at 2:34, and 3:13 but, rather, some time X and some time X+1. And, the time one minute thereafter is not "3:01" but, rather, X+2.
The problem lies in relating these time changes to the user's "context".
Consider how you might relate a log of his "time changing activities" to him if he choses to examine it at "3:01" on the day in question:
- the first change appears to have happened ~30 minutes ago (at 2:34) even though it actually was only two minutes ago!
- the second change appears to have happened ~10 minutes in the *future* (at 3:13) almost 40 minutes after the first change -- even though it happened just *one* minute ago.
Of course, these types of things happen all the time when you play with the time on a desktop machine (probably not as noticed on Windows machines as they don't tend to generate ongoing logs of events that would manifest these "anomalies"). On a server, changing the time can cause you some unexpected grief (e.g., if a cron job doesn't run because you "skipped over" its scheduled activation time). But, chances are, you are skilled enough to compensate for this
*if* it is important.But, how do you deal with this in an *appliance* used by "nominal users"? To date, most such appliances/devices haven't had the level of sophistication to support scheduled events (other than, perhaps, reminding you of a pending birthday, meeting, etc.) of any substance. What happens when the *device* needs scheduled activities for its own maintenance/integrity?
One approach is to schedule all of those using "system time" so that changes to "user time bias" do not affect it. This works great if you can hide the activities from the user. But, if you have to disclose them to the user, you run the risk of adding the same sort of confusion.
An even bigger issue (that I won't get into as I haven't any *good* idea of how to solve it) is how you tell the user about his *past* actions and *future* plans in the face of varying "time biases".
As I said, an "interesting" problem without a clear cut answer. :-/