This isn't really so much of an issue. Most computers for which such things are really important use UTC (formerly GMT) as their reference point for time. There is no "daylight savings" or other silliness in UTC time, thank goodness.
Unix-based computers, for instance, generally have clocks that run UTC. When you ask the computer what time it is, it checks for an environment variable called, appropriately enough, "TZ", then it calculates what it should be displayed based on the value of this variable. If this variable is unset, it checks a file called in the /etc directory called "timezone" and applies the calculation to that. If that file doesn't exist, it displays UTC/GMT time. This time is based on the number of seconds that have elapsed since Jan. 1, 1970. Leap seconds cause problems with this system because the conversion from the number of seconds since 1/1/1970 is actually greater than it was initially expected to be, thus in an absolute sense generating the precise date from the number of elapsed seconds gives an incorrect answer.
In a practical sense, this is generally worked around a number of different ways. I recently read a really interesting white paper about discussions that have occured at various IEEE and IETF sessions on the matter. One solution might be to include a lookup table that contains the dates that these leap seconds are added so the conversions would be more accurate. It actually all gets very cloudy inside the workings of how these conversions could or should be done, but it is an interesting problem IMO, as I've always been pretty interested in timekeeping, and the history of it.
We'll, that's probably more than you ever cared about reading about this stuff, so I'll stop now.:-)
Unix time will not have any problems until the year 2037, because of a potential floating point error. Like Y2K, this will be dealt with properly.
Info from the USNO (and I thought GPS clocks were on time!):
U.S. NAVAL OBSERVATORY
WASHINGTON, D.C. 20392-5420
July 27, 2005
No. 69
TIME SERVICE ANNOUNCEMENT SERIES 14
UTC TIME STEP
1. The International Earth Rotation and Reference Systems Service (IERS) has
announced the introduction of a time step to occur at the end of December, 2005.
2. Coordinated Universal Time (UTC) will be retarded by 1.0s so that the
sequence of dates of the UTC markers will be:
2005 December 31 23h 59m 59s
2005 December 31 23h 59m 60s
2006 January 01 0h 0m 0s
3. The difference between UTC and International Atomic Time (TAI) is:
from 1999 01 Jan, UTC to 2006 01 January, UTC: TAI-UTC= +32s
from 2006 01 Jan, UTC until further notice: TAI-UTC= +33s
4. Information regarding current and predicted values of UT1-UTC is provided in
IERS Bulletin A.
5. UTC and all time scales based on UTC will be affected by this adjustment.
However, Loran-C and GPS will not be adjusted physically. Times of Coincidence
for LORAN-C are available on the Time Service Web Page
(http://tycho.usno.navy.mil/loran.html). For GPS, the leap second correction
contained within the UTC data of subframe 4, page 18 of the navigation message
transmitted by satellites will change.
Before the leap second
GPS-UTC = +13s (i.e., GPS is ahead of UTC by thirteen seconds)
After the leap second
GPS-UTC = +14s (i.e., GPS will be ahead by fourteen seconds)