There are two considerations: how we represent specific dates and times as we use them in the real world, and then how we measure the progression of time on a computer.

Representing specific dates and times

Our system for using dates and times is unusual as it doesn't follow a decimal system:

What bases are we using?

This is all a legacy of using the Gregorian Calendar (an arithmetic system based on the rotation of the Earth around the Sun and the Moon around the Earth) and the Sumerian sexagesimal time system. This is a bit messy, and our lives would be easier if we used StarDates, but even those have problems!

As it happens, it isn't too much of a problem. There are four simple ways we can store dates and times:
  1. Using ASCII text
  2. Using separate integers for year, month, day, hour, minute (and sub units like seconds, milliseconds, etc, if needed)
  3. Compressing the date and/or time into a smaller number of integers
  4. As elapsed time from a given point using one particular unit (e.g. seconds)

We often don't need to store the day of the week as this can be calculated from the date. Most of our problems are problems of human convention, rather than problems of accommodating the computer's way of doing things.

When using 1-3, we should make sure the date and time is in a standardized format. There are several ways of writing dates and times, depending on culture and location. For example, all the following are the same date and time:

01/27/2009 1.30pm
JAN-27-2009 1:30pm
01/27/09 1.30pm
27/01/2009 1.30pm
2009/01/27 13:30

This issue, along with sorting concerns (see below), led to the development of ISO-8601 - standardizing communication of dates and times (see also ISO page). This is recommended to be used for ALL date formats (you can always convert to other formats if needed). It's basically a YYYYMMDDHHMM format. For example, the above date would be represented as

2009-01-27-13-30 (or even 200901271330)

Compressing the date can be done in a variety of ways, but the commonest is to use 2 integers, one for date and one for time. For example 1.30pm on 27th January 2009 can be represented as two integers (how many bits do we need??):

20090127 1330

Sorting considerations

One of the biggest concerns in using dates and times is being able to sort them into chronological order, and extract based on date ranges (for example, we might want to recall all of the entries in a database from 1999-2009). This is not too difficult if we use an ISO-8601 format, even if we use ASCII (so long as we use trailing zeros). For example

200901271330 > 200901270930
200901260000 < 200901270000

Other concerns

Representing the progression of time

As well as storing arbitrary dates and times, computers have to be able to answer questions like "what time is it?", "how long did this program take to run?" and so on. This is facilitated by a System Clock which counts the number of time units (e.g. milliseconds) that have elapsed since an arbitrary starting point. For many Unix systems, for instance, this "epoch time" begins January 1, 1970. The elapsed time for a given process can then be measured by subtracting the start time from the end time and multiplying or dividing to get the right units. For example, if the system clock stores milliseconds, then the time for a process in seconds would be (end time - start time) / 1000. However there are some problems: e.g. inability to incorporate leap seconds, and the Y2038 problem.

For most purposes we measure wall clock time, i.e. the "real world" time that has elapsed. However, sometimes we want to measure CPU time, i.e. the amount of CPU time that has been devoted to a particular process. This latter concept can get tricky when dealing with parallel computers and the like, but it is out of scope of this course.

Case study: the year 2000 (Y2K) problem

This was a stupidly trivial sorting problem caused by systems which only used two digits for the year. See description on the Wikipedia page

It still hasn't gone away - introducing Z2K9!

AND.... here we go again..... Jan 2013, the Z2K13 or "Apple Do Not Disturb Bug"!

(see page for this)

Case study: the year 2038 problem

See description on the Wikipedia page and also code examples and fairly technical programming recommendations.