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".

I am also with you on the user having whatever time-frame reference he/she
desires. Quite pertinent for the travelling person who might visit many
time-zones. I don't think that they would want anything other than the local
time wherever they happen to be at the time. Helpful if the item had
reference to a GPS and could determine the local offset for them, then the
user needs not be bothering with time settings at all.

As for logging of "Time-change" events, not something I would consider
relevant if you can automatically determine correct UTC and local zone. It
might be pertinent to server farms but I would expect them to be at UTC
anyway.

For example, you *know* that system time N and N+1234567
are exactly 1234567 seconds apart.  For *all* values of N.

I see synchronizing to UTC (or any other standard) as just
another "user time bias" adjustment.  UTC exists solely
for the convenience of users who want to think in terms
of UTC.

The system shouldn't (can't?) care if the user wants to spend
his entire day setting the clock forward, then back, then
forward some *different* amount, etc.

What I was looking for (i.e., the purpose of my question)
was insight in how people *think* about time (as users)
and what characteristics of a "context" affect that thinking.

E.g., scheduling a (doctor's) appointment happens in an
"absolute time context" but setting an alarm when baking
*cookies* happens in a "relative alarm context".  I can
come up with numerous examples for each but haven't been
able to come up with a criteria that can be used to
categorize them.

For example, an initial criterion that I toyed with was
the "temporal distance" -- things in the near future
tended to be relative; those "further out" (whatever
that means) tended to be absolute.  But, deciding where
that threshold was proved to be just as hard a problem
to solve.  And, I can come up with counterexamples of
each.

Note that the application can't unilaterally make this
decision, either.  E.g., the two examples above would
easily fit into the same application.

On SCO the lbolt variable was initialised to 0 at boot and incremented
every 10ms after that.  After a little over 8 months the variable
overflowed and turned negative.  Problems this could cause drivers
ranged from garbling I/O during the overflow period to panicing the
system.  Of course, a problem that does not occur for 8 months is
easy to slip through testing unless you are specifically looking
for it.

Although the exact example you give is valid, closely related
examples may not be.  You can't assume that if N is now then 12345.67
seconds time will be represented by N+1234567.  Nor can you even
assume that if A is less than B, A must represent an earlier time,
even if we know from context they can be no more than a few seconds
apart.

Note that leap seconds can also *subtract* a second (though
this has never? happened)

*All* "human formatted" time schemes are PITAs for machines.
The only realistic way to track time is just to count seconds.
(or some other time unit having the granularity you desire).

Intervals can also be long or short:  From the 4-millisecond
exposure time for a digital camera to the end of the 7-year
warranty on your Prius battery pack.  (For intervals above an
undefined limit, it probably makes sense to convert the
end of the interval to an absolute time.)

For short-term interval measurement, there's really no need
to use  a system time variable at all.  It's often simpler
to just increment a delay-specific variable of the appropriate bit
length with a timer tick.   After all, when you're setting the
baking time for your brownies, you don't want to go to the trouble
of adding 30 minutes to    6/11/2010 23:47:33 and set that
value into the timer.  You just want to twist the knob to the
right until the arrow points at '30'.  ;-)   OTOH, if you
want your alarm clock to go off at 7:00AM, you don't want to
figure out the difference between now and that time, and set
that into a countdown timer.

Then there is the subset of timing problems like a desire
to have the alarm go off at 7:00AM every day.  The first
setting is an absolute time---but the following settings
are intervals of 24 hours.

I guess my conclusion is that  one time system won't work
for all problems.  As for picking the right system---it
probably depends on whether the question you ask the user
is "How Long...."  or  "When do you want to....".   The
second question implies that you and the user have some
common time reference.

The technical problems only  get worse when you think about multiple
systems,each with a unique system time, having to accomplish some
action at the same instant----without the capability to communicate
with the other system(s).    I face this problem often with
moored oceanographic instruments.   My solution has been to
use low-drift clocks and synchronize the logger clocks to
UTC.  

Generally, I don't ask users questions.  Instead, I try to
glean what they want from their actions.  (this makes a
friendlier user interface; one where the user feels in
control and where the "device" isn't intruding on their
way of doing things but, rather, *assisting*).

But, think of how *you* are often driven by other people
and events.  E.g., a doctor sets up an appointment for you
to come back "in two weeks".  Yet, they pen the appointment
at a *specific* time/date.  To you, that is an absolute
time reference (you are expected there at that time/date).
Yet, to "the system" (the system being the doctor, you,
society, etc.) it really is a relative appointment.
I.e., if the doctor had to reschedule, he would have
knowledge (unbeknownst to his appointment book) that
*exactly* two weeks from "now" is just a guideline...

(yes, I can see how to *use* either of these specifications.
But, you have to be able to react to how the user wants
to express the time and still not necessarily know if
he is being absolute or relative. People can too easily
think in either basis and express time either way.
E.g., think in terms of reltive time yet express an
answer in absolute time or vice versa.)

But, as my comments (elsewhere) should indicate, it may
not even be possible for that application to *know* how
to deal with the time change.  E.g., the user's notion
of current calendar time may have changed but *relative*
time progresses at the same pace; how do you know which
times are absolute vs. relative?

This is my point:

NOW is always "now".  "This instant".  Everyone has a coincident
"now" -- regardless of what the time on their wall clock says.

"An hour from now" is exactly that 3600 seconds from "now".
We will all experience "an hour from now" at the same
instant in time -- regardless of where we are (on this planet).

Your NY/CA example doessn't go far enough.  If we agree to meet
at 1700 in CA, then CA local time applies.  Presumably, my
timepiece would reflect CA local time when I am *in* CA.
But, what happens if I opt not to travel to CA?  What (local)
time must I place a phone call to you if the meeting is to
be held as a teleconference?

How do we know that our individual notions of PST and EST
are synchronized?  What if I tend to set my clock 5 minutes
fast?  Etc.

The point is, time only makes sense when given a reference
along with the time.  Whether that is relative or "absolute".
But, people almost *never* express those references when
they are speaking about "times".  So, how do you *infer*
it?  Or, present an interface to the user whereby he can
specify it without feeling encumbered?

--