[Tfug] A sense of time

[Bexley Hall]

--- jblais <joe.blais at pti-instruments.com> wrote:

> > I've periodically posted this question (or
> variations
> > thereof) in a number of different forums. 
> Obviously,
> > never quite happy with the answer(s) I've received
> > (I suspect it is yet another unsolvable problem 
> :< )
> >
> > The issue is tracking calendar time in a system
> > that exposes it (in a variety of forms) to the
> user.
> > And, where that user is capable of "changing" the
> > "current time".
> 
> How about every time the user sets the time, you
> write a sync time --
> battery time vs cpu ticks - to a file.
> Whenever the machine boots, look at the battery
> saved time and adjust the
> sync file/time.
> You define your events in terms of cpu cycles & cpu
> cycle counter wraps (a
> little ways beyond base 10 counting).
> When it's 10:02:13.1234 and  10897132691287 cpu
> ticks, and an event is
> defined for 12:00, it might equate to an alarm time
> of 1 wrap + 8723986
> ticks.  So that's the effective alarm time.  If the
> user changes his display
> clock so he won't be late, the problem becomes: did
> he mean to set the alarm
> for lunch, or when the sun was high?  He might
> change his lunch schedule,
> but can't affect the sun.

(sigh)  I guess my comments must be distracting from
the "real issue" -- what I consider the inherent
(unsolvable) paradox.  Stop thinking about
technology and technological solutions.  The
problem is in the brain of the user!  What I am
looking for is a good model that will help reform
that user's expectations (Principle of Least
Surprise) so that I can implement something that
he can *learn* to "accept".

Very few people are system administrators.  Even
among them, I suspect they just ignore anomalies
in timestamps and figure it will work itself
out, "eventually" (e.g., files eventually get
deleted; if a database restore ends up slightly
out of kilter because some records were stamped
"funny", sooner or later the appropriate USERs
will find and fix the problem -- and blame it on
The Computer, etc.)

Most machines are used by Everyday Joe's <grin>.
They don't *want* to know about all of the crap that
goes on inside the machine (appliance) -- any more
than most TFUG subscribers care about the chemistry
involved in internal combustion!  (i.e. they just
want to step on the gas pedal and have the car *go*!)

I've yet to meet a person who has NEVER adjusted
the timie on his wristwatch, alarm clock, wall clock,
microwave oven, PC, PDA, etc.  People *want* to
change machines' notions of "The Time" to agree
with their *expectations* about The Time (i.e. setting
an alarm clock "fast" so you get up 5 minutes earlier,
etc.).

So, user's must be able to set *their* notion of
time and the machine must adapt that IN ITS
INTERACTIONS WITH THAT USER!  (the machine is
free to think in units of 1.7 picoseconds or
any other unit of measure it wants to use for
*its* sense of time).

The problem arises because the user isn't
constrained to think in any given way about
*changes* in that definition of time THAT HE/SHE
IMPOSED ON THE SYSTEM!

So, it is equally possible (likely??) that he
can be "surprised" by timestamps that are NOT
adjusted to reflect his new sense of time as
he can be surprised by timestamps that ARE
adjusted.  Damned if you do, damned if you
don't!

What I am looking for is a way to relate time to the
user in such a way that he *accepts*, intuitively,
the "value" reported to him without balking.

E.g., if I tag things with absolute times, then
those absolute times will, by definition, not
correlate with his expectations if they exist in
the "wrong" time sense (than his expectation).

A possible solution is to relate times to him in
a relative fashion -- "that email was sent 57 minutes
ago" -- instead of an absolute reference frame.
I.e. 57 minutes ago is always 57 minutes ago even
if he has set the time of day clock forward by 38
hours!!

But, I don't think people would be comfortable with
times expressed in this way.  The only other scheme
I can come up with is to record the "real" time
(from an unalterable hardware ToD clock) along with
the "time sense in effect" for each event.  Then,
the user can elect to see the time reported in
whatever scheme he deems appropriate (though the
user interface for doing this would be prickly).


       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469