[Tfug] A sense of time

[Bexley Hall]

--- James Hood <ebenblues at yahoo.com> wrote:

> > To put this in terms of a desktop environment,
> > imagine the user creating a file.  Then, changing
> > the time.  The *next* file created (*or*, any
> > modifications made to this previously created
> > file) will bear a timestamp in this new
> "timespace".
> > 
> > E.g., create a file at 1:00PM, set the time to
> > 11:00AM and create a second file -- the second
> file
> > *claims* to have been created before the first!
> 
> This isn't a bug, it's a feature! ;-) Changing the
> system time can help you get around those pesky 30
> day trials on software. It's fun to change the
> system date on your computer and watch how it
> changes your "Recently added songs" list on
> iTunes...anyway...

<grin>
 
> > I *think* the right solution is to treat time as
> > continuous and just let the user's *idea* of
> > "current time" FLOAT in this continuum (e.g., I
> > have a set of "clocks" -- timepieces -- that
> > track "real" time but allow the user to define
> > an *offset* used in all DISPLAYS of time... so
> This is the solution I would have suggested. From
> the OS level, don't let the user ever change the
> hardware clock. When they modify the date/time in
> some configuration GUI, take the delta of the time
> they set and the hardware clock value and use this
> to return the time to any program that asks for it.

If you think about this for a moment, you'll see
that it doesn't work in the context of a desktop
environment, etc.  E.g., it "works" when applied
to (wall) clocks (i.e. timepieces) because any
problems brought about by any inconsistencies
or nonmonotonic behaviour are outside the scope
of the timepiece -- since all it has to do is
*report* the time and never has to worry about
*acting* on that time!  OTOH, if the user has
set time "backwards" by one hour (e.g., DST),
then he/she has to deal with the consequences
of that action (i.e., 1:59AM exists *twice* on
that day...).

But, in a desktop/appliance environment, even
letting the time "float" is exactly the same
problem as letting the user tweek the hardware
clock!  I.e., if he "floats" time back one hour,
he expects to see the timestamp on NEW files
reflect that "new" sense of time, not the "old".
So, a file created just before he set time back
appears "newer" than the file he created just
*after* setting time back!

The logical alternative of stamping the files
with the *hardware* time and *displaying* those
timestamps in the context of the *current*
"time sense" still doesn't work around the problem.
Granted, a file that he creates just before setting
time "back" will now show a *relative* time that
is "correct" wrt the file that he creates immediately
AFTER altering the time sense... but, now his
relationship to those past times (timestamps) is
mangled...  "I thought I sent that email at 5:00PM
but, when I look through my sent mail folder, I only
see a message that was sent at *4*PM... <shrug>"

If you think this through, I think you'll see that
it's just not a solvable problem.  You can always
argue that the user *may* want some time relationship
that he you aren't providing for him (i.e. if you
keep the "original" timestamps, then those timestamps
don't reflect the *real* timing/order of events;
yet, if you *adjust* those timestamps per the
current "time sense", then, by definition, they lose
their ties to "actual" time...)
 
> If you're writing a program outside of the OS, then
> I don't think there's a way for you to ensure your
> clock will not be changed out from under you by the
> OS.
> 
> > I just haven't been able to come up with a scheme
> > that is easy for a user to relate to in more
> complex
> > devices (e.g., the desktop/workstation
> environment)
> 
> I'm confused by this. Why surface the complexity of
> your implementation to the user? All they should
> know is that they set the date/time to a certain
> value and now all of their display times have
> changed to match. Maybe you're referring to the fact
> that timestamps on files might change if they change
> their system time?

Because *lots* of things are tied to time!
E.g., the time at which emails were sent;
the time jobs are scheduled to run; the time
files/etc. were created/modified;; etc.  This
is why it is an easy solution for a "wall clock"
but still plagued with "issues" for an appliance
or desktop environment... :<

--don


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