(feel free to comment at any time to hans.lammerant@telenet.be)
The experience of time is an essential element of any form of experience or cognition. Emotions depend to a large extent on expectations, or the potential coming of a future event. Any observing or experience of difference, of presence related to an earlier or later absence, is linked with an experience of time. However, how the actual experience of time is shaped is strongly influenced by all sort of design decisions and implementations, both for humans and machines. Also, the experience of time is a conglomerate of different experience: time as a common moment, the duration of a certain time, time as cyclic events, historical time, ... Researching how humans and machines experience time and negotiate their time experiences is therefore an interesting avenue to explore.
Humans have developed a time experience which was linked to natural life cycles, but it has been influenced by both technology and social conditions.
A first time cycle is the day-night time cycle. Humans do their stuff during the day, but need to sleep. The night is generally the preferred time for sleep, but the availability of artificial light and the need for longer-distance coordination has influenced how humans dealt with the day cycle and the place for sleep in it. Time measurement also developed: early time measurement was linked to observation of natural circumstances like sun set and sun dawn. Measurement of such sun cycle (which is in fact an earth cycle) through sundials allowed for a more precise time referencing, but this was very place and season dependent. More light during summer than winter implied that hours were longer in summer than in winter. Similarly such changes were larger at higher latitudes, while near the equator such changes are non-existent or limited. In other words, time measured by sundials provided a local common reference of time, but not one over longer distances.
This seasonal time experience when the human world was flat reflects the unknown spherical geometry of the earth cycle projected on the flat earth. When humans became aware of earth as a sphere, they responded by flattening and linearising time. Mechanical clocks allowed to unify time lengths and thereby also standardise time. Physical observation and all sorts of economic processes needed such standardised time measurement. Early versions of such time measurement, like hourglasses, existed but remained disconnected from day time measurement. Mechanical clocks thereby also allowed to unify different time cycles and scales. This also allowed standardisation of time over longer distances, departing from the local sundial time to time zones, which were less strictly linked to the seasonal rhythm of the sun but more to geographical zones. Long distance trade, industrialisation and later long-distance communication by electro-magnetic signals (comparable to the speed of light) demanded more geographical coordination. In the 19th century coordination developed through clock networks, with a master clock driving the slave clocks. Nowadays we work with atom clocks and a global Coordinated Universal Time or UTC as a reference to which geographical time zones are connected. Humans organised their activities accordingly, if necessary by de-linking from the solar rhythm. The borders of time zones diverge very often from the longitudinal lines for economic and political reasons.
A similar socialisation and globalisation of time occurred for computers. Where in the early computer age time was set and counted locally by each machine, it is now common to continuously synchronise time over the internet through time servers and the Network Time Protocol. Humans get woken, cron jobs get triggered, precision bombs get guided and trains count their delays in measure with the drill signal of the Master Clock of the US Naval Observatory, although with varying latency times.
Humans also developed ways to relate to time on a longer scale, which were originally linked to natural rhythms: years, life cycles. Calendar systems were used to determine seasonal agricultural needs (when to plant, when to harvest), while they also allowed to keep track of life cycles and historical time. Again, such calendar systems have been very diverse and local, but got slowly fused to a couple of dominant models. Generational or birth, life and death rhythms, originating from the human experience, have been projected on all sorts of phenomena. Religions tried to explain the origin of everything, while also often predicting the end in apocalyptic visions. The demise of religion at the hand of science did not let such generational visions disappear. They got new expressions in scientific theories of the beginning (big bang, evolution) and end (the heath death of the universe, the end of the earth at the final burnout phase of the sun) of everything. Similar apocalyptic visions are now embedded through technological design decisions (Y2K, the end of Unix-time in 2038). In all versions the end is often linked to the specific design of time (e.g. the end of the Maya calendar, millenarian movements). But just like religious visions can extend their apocalypse in a new versions (e.g. the always near but always delayed apocalypse of the Saints of the last days), machinic accounts of time can always be extended by enlarging the bit size of the time range (cfr the extension of Unix time till AD 292277026596, or safely after the end of the observable universe according to contemporary physics).
Also machines have their natural cycle: the vibrating pulses of its internal clock drives the cycles according to which the processor works. The time of the computer is linked to this clock cycle, as it consists in counting cyclical ticks. This produces a cyclical time rhythm in the hardware, on which time experience in the software is based.
However, time in a computer is no unique or unified experience. Several hardware components and a diverse collection of software organised in layers and processes create a whole ecology of interdependent time experiences. The operating system experiences other software components, and users through them, as a bunch of processes screaming for attention. One of the most pushy interrupts is the timer forcing the processor to count another click and update the system time. An internal kernel process performs the negotiation of time through which the clock count is linked with a system time.
This system time gets communicated to all other processes when demanded. But the process time is completely different. Most of the time processes are put on hold and when the scheduler gives them time they can proceed till the next on hold is forced to make time for another process. The scheduler is the big organiser of time in the internal ecology of processes.
System time is externally counted and therefore an external global variable to these processes. They have all their means to send a demand to the kernel to get the system time. This gets communicated through the software stack with a range of system calls of the kernel and through the specific time modules of the programming language the software is programmed in.
The difference between the actual process time and system time does not appear in how time is perceived by the process. The process only perceives time as the difference between two demands of system time and is oblivious of its time being put on hold. The processor on the other hand spent most of its processing time as idle time: a processor is doing time waiting for slow system components like memory and even slower hard drives and network connections to respond and switches between checking for responses of these laggards. L’enfer du temps perdu, ce sont les autres.
Connecting computers into a network demands new negotiations of time. We already mentioned the networked and globalised UTC timekeeping. But temporal negotiations happen on all levels of the system. Network protocols have timed choreographies to make connections and proceed with communications, with time out failsafe to break off when something goes wrong. The timing of an action is an essential component between a meaningful signal and noise. Using a browser over http to connect to a website, or better the server providing the website on your request, is built on a discontinuous time practice. In a REST architecture the server just deals with a queue of requests and does not see continuity over time between certain requests from a single user. New temporal practices have been designed and technically implemented. Through cookies the server is able to recognise users and their state in time.
fuzzy borders: external software watching /external software dropped on your computer and running on your processor (Javascript)
browser as a border where time gets negotiated
Renegotiating time with your computer
Technology has been a tool through which humans created distance with natural cycles and designed its own time experiences.
Is it possible to reconfigure the time of the computer and rewire the connections with human and natural rhythms? We can try to design another time experience in the functioning of the computer. Would we be able to let the computer function in an older human time experience, e.g. the time of the sundial? How can such sundial experience be built into the system and what would be the impact on the user?
Sundial time is a geographically and seasonally localised time. It also includes a distinction between day and night. The night is ‘out of time’, This distinction has been extradited from linear time practices, where the amount of light is just a variable external to steady beat of time. Linear time allows to turn the night into economically productive time. Running your computer on sundial time re-introduces the night in your system.
On which point to intervene: time count processes, scheduler, system time, recalculating the time negotiated across the network, ...]
Letting a computer run on sundial time is a conscious effort to disconnect it from human-made linear time and to reconnect it with the old earth-driven cycles and the ancient time experience by humans. This re-enactment of such cycles through the computer will remind human users that the experience of time is a socially negotiated and technically implemented experience, and also why they tried to escape from these earthly rhythms through technology in the first place.
WTC time: the building boots up at 9AM and is turned off in several steps (17.00: air conditioning is turned off) into a wake state (concierge can let you in and out through the night side entry, but main life support systems remain turned off outside office hours). This wake state continues during the weekend, turning the building in a glass house with limited air in storage.
Such office time can also be implemented and negotiated at system level: PoC adapted bashrc at etherbox simulating a system reacting differently outside office hours, getting bored and stealing time, aging (slower when timestamp of original install is more remote in time), etc.
Time(s) of the cloud
Synchronisation tools like etherpad and Google docs: how do they differ?