[Tfug] A sense of time

[Rich]

Okay, bearing in mind your clarifications on your (imagined user's)  
expectations:

On Aug 2, 2007, at 4:05 pm, Bexley Hall 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".
I guess the way to solve this is to use the existing several layers  
of abstraction in new and exciting ways:

1. system 'pendulum'
	- this just ticks and updates the level 2 clocks
2a. uptime
	i. interval since boot
	ii. continuously saved
2b. hardware clock
	i. real time
	ii. user can change it
	iii. NTP can adjust it
3a. system events
	i. system-level timestamps (cron, files)
	ii. based on clock 2a. uptime
	iii. always UTC
	iv. timestamps are calculated from hardware date
	v. timestamps with large discrepencies from 3b. marked "SYSTEM"
3b. calendar events
	i. user-level events (calendars, email)
	ii. based on clock 2b. hardware clock
	iii. changing 2b. can screw up the order of these

Now we have a problem: 3a. takes precedence over 3b. for "important  
system stuff", but vice versa for human events. Overall, human events  
are more important than techie stuff any day (no, you can do it!  
breathe deeply!), so some way to re-sync 3a. to the authoritative 3b.  
is needed after a clock change.

This re-sync process could be done by advancing or delaying 3a. (say)  
20% until the difference is made up.

However, 2a.'s rate is never altered. So two files with timestamps of  
"2007-08-07-01:34" and "2007-08-07-02:34" could have been created   
between 72 and 48 minutes apart. Even though it's wide, this range  
still usefully represents a human concept of "an hour". Scheduled  
tasks would still be executed.

Finally, we need an improvement to cron: system events which need to  
be executed say, 60 minutes apart, should be explicitly stated as such.

Okay, I'm bored. Was this useful?

R.



>
> 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!
>
> While this is obvious, the effect is also present in
> many other (often subtler) cases.  E.g.,  you can't
> *look* at any two timestamps and deduce anything about
> their relative order in "actual" time (isn't the
> purpose of a timestamp supposed to be exactly this??).
>
> It also leaves open the possibility of creating
> "holes" in time.  E.g., if you schedule a job to
> happen at 1:05PM but, at 1:04PM you advance the
> ToD clock to 3:45PM, then "1:05PM" never happened
> (sure, you can design your system to treat everything
> between "the time I last checked the list of jobs to
> be performed" and "the current time" and run any and
> ALL that fell into that interval... but, that means
> the job that was DELIBERATELY scheduled to occur at
> 1:15PM -- well AFTER the 1:05PM job -- will end up
> running roughly concurrent with its intended
> predecessor... so, any races that you sought to avoid
> will now manifest).
>
> I've tried various "solutions" to this problem in the
> past but have not been happy with any of them.  :<
> I think the problem lies in defining/assuming what
> each time "specification" (i.e. the point at which
> a reference to a time is "defined") is intended to
> mean.
>
> For example, when I write a routine to blink a light
> at 1 Hz, I don't create an "alarm" at "now+1 second".
> (i.e. if now is 07 Aug 02 12:34:56 I will not set
> an alarm for "07 Aug 02 12:34:57") but, rather, I
> will do a "relative" wait (i.e. delay) for 1 second.
>
> Yet, when a "user" thinks in terms of time (like for
> *appointments*) they are usually thinking of absolute
> times (i.e. "I have a doctor appointment on 3 Aug
> at 4:15PM") and *not* "relative" times (i.e. "my
> doctor appointment is 28 hours, 34 minutes and 18
> seconds from now...").
>
> This is important because it suggests how you can
> treat times in different contexts (i.e. relative
> times IGNORE changes in the ToD clock whereas
> absolute times tend to *follow* them).
>
> Of course, there is nothing that *forces* a user to
> think in these terms.  I.e. they can easily convert
> relative time to absolute time before specifying a
> time reference (I.e. "I want to take a one hour nap
> so I will set the alarm for 3:45PM since it is 2:45PM
> currently").
>
> 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
> you can set the clock by your bed to be "10 minutes
> fast" to trick you into getting out of bed "on time").
>
> 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)
>
> Suggestions?  (off list if others aren't interested
> in this musing)
>
> Thx,
> --don
>
>
>
> ______________________________________________________________________ 
> ______________
> Need a vacation? Get great deals
> to amazing places on Yahoo! Travel.
> http://travel.yahoo.com/
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org