[Tfug] A sense of time

Fri Aug 3 04:00:57 MST 2007

I think one question is, do you have a particular 
task / problem domain / UI design situation / etc.
for which you are seeking a good specific usable answer...

...or are you just looking for a general, universal, perfect answer
to a question that is large and, like most questions grounded in
human language and humans' fuzzy notions of abstract concepts, 
ill defined? :-)

'Cuz you ain't gonna get that general, universal, perfect answer
to that second kind of question.  The question only even exists 
in a vague kind of way. :-)  

Might do better to try to measure the location of an electron 
with error far smaller than its de Broglie wavelength. :-)

If you're just looking to implement an answer usable by software
that needs to try to figure out "how long has it *really* been"
since some event, I suppose you can set up a daemon on the system
in question, that periodically (fairly frequently) 
checks the supposed current time
(by whatever interface(s) are locally available and of interest)
and writes a running record (including any observed discrepancies)
to one or more logfiles, which can be used to try to reconstruct any 
differences between the alleged passage of time and the probable actual 
passage.

Of course, events that you *really* want to know the time of
can be logged to this file as they happen.

Comparing nominal date-and-time data with 
"the system ticker which starts when the machine is powered up", 
to quote jblais, also seems like one of the good ways to notice possible
discrepancies for the daemon to log.  

If you want to be able to specify a 'relatively unique point in time'
when something happened, you can refer to points in the logfile.
I mean, a log event in the logfile refers to a relatively
unique *point* in "time", but you might have to rely upon inference-based
approximation when trying to convert from this 'relatively unique point'
to, say, GMT.

So in general, I think I'm agreeing with what I think jblais is
generally getting at, and probably going somewhat beyond.

Oh!  I better go out and apply for a patent! :-)
I wouldn't want someone else to file for a patent on this
idea first and get an inapppropriate monopoly, when I could
hope to get an inappropriate monopoly for myself! :-)

Also, since you mention the topic specifically:
to avoid races between scheduled jobs that are intended
to happen at different times, simply never schedule jobs
separated by any interval that can be the same size as
a skip that can happen when changing time zones 
or adjusting for daylight savings.

Also, try not to schedule at times that are likely to be chosen
for daylight savings time adjustments, such as exactly on
the hour.

So, for example, never schedule your jobs an hour apart.
Or fifteen minutes apart, in case someone is crossing
a time zone boundary in Australia.  Etcetera. :-)

So people who schedule an event to happen every hour
on the hour exactly?  How irresponsible! :-)

Those people are dreadful obstacles to efficiency and efficacy!
They are servants of chaos!

It would make more sense to use a random number generator! :-)

Actually, a random number generator used with a good probabilistic
algorithm, and probably some kind of semaphore or similar sort of
(non-)synchronization device to keep two things from happening at 
*exactly* the same time, could be a decent way to schedule jobs sufficiently
often, but not too close together.  

But since some people in this group are put off by vague references
to large abstract categories defined in the computer science literature,
and would rather see references to highly specific algorithms 
that they see in specific hardware they use every day, 
maybe I should just say, "Hey, doesn't Ethernet do something a lot like that?"
(to deal with collisions between multiple devices on the network trying
to use a communications channel at exactly the same time)

Having supplied this concrete example, 
I am free to go eat spaghetti with some dining philosophers
should I so choose.

Also, I think I've filled the group's minimum quota for semi-off-topic BSing
for the time being. :-)

Chris

At 04:05 PM 8/2/2007 -0700, you wrote:
>Hi,
>
>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".
>
>The problem creeps in when time is changed by the
>user -- either *correctly* or *incorrectly*.
>
>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!
>
>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
>