Calendars, Time & Bugs: Y2K, Y2004, Y2038, Y2106, Y4K
The impending y2k20 crisis in 2020
Browsers in 2020 will expect to "connect HTTPS" only using TLSv1.2 and
TLSv1.3 (this assumes that support for everything from SSLv3 to TLSv1.1 will
While browsers are constantly being updated because of their financial use in everything from on-line purchases to on-line investing and banking,
many web servers are not. What is worse it this: many organizations, including
governments large and small, are slow to update software
Overview of y2k (2000) vs. y2k20
- Y2K (in the
year 2000) was a problem related to old technology (both hardware and
software) where it was not certain if internal clocks would know how to
handle these two problems:
- would clocks properly roll over from 1999 to 2000 or would they wrap
back to 1900?
- would the year 2000 be a leap year or not? (it was a leap year
according to rule-3)
- notice that these human-caused problems where caused by:
- a lack of coordination in the computer industry (caused by
companies competing with each other rather than working together)
- businesses and governments refusing to upgrade
- egotistic programmers doing their own thing rather than calling
the operating system
- Y2k20 (in the year 2020) is a potential
- security changes in client browsers (which are usually
auto-upgraded) may not be able to communicate with web servers (which
are not auto-upgraded)
- this is a client-server problem
- security changes in web servers (depending upon how they are
implemented) may not accept connections from customers unwilling or unable to
- this is a B2B (business to business) problem where third
party software (usually linked to older OpenSSL libraries) is used
to initiate a web connection.
Why is 2020 going to be a problem?
- y2k was (perhaps) so overblown that
many people assumed that a whole lot of money had been spent but nothing
happened. This assumption is faulty because the problem was
- y2k20 does not appear to be taken seriously by
- back during Y2K, not very many people relied on browsers
- twenty years later, almost everyone relies upon browsers for
- email clients have gone the way of the dodo (Microsoft will not
allow you to install Windows Mail on a new Windows-10 platform);
most companies tell you to read mail using a browser
- many people uses browsers for online banking; online investing;
online purchases; online entertainment (eg. youtube)
- programmers aside, anyone who used a terminal emulator back in
2000 will most likely be using a browser today.
- to save money, many companies are not patching internal
web-servers which are only accessed by internal employees on their
internal intranets. But their employees are still agreeing to
upgrade their own browsers. Kaboom!
- Don't think this will affect you? An unexpected change to OpenSSL to
CentOS-7.3 in January of 2018 broke a few things for me as I have
Daylight Savings Time + UTC (Universal Time Coordinated)
Before the age of internet connectivity, computers were set to the
local time of their operators. When the local time zone would change between
Standard Time and Daylight Savings Time, either the
computer clock was changed on the fly (on systems that allowed it), or it was
changed during a reboot. These two methods have short comings which became more
apparent after computers were connected to the outside world for
the following reasons:
It is for the above reasons that some computer operating systems (like all
modern Unix and Linux platforms) allow for easy synchronization to a world
standard known as UTC (Universal Time Coordinated). This is
similar to, but not exactly the same as, GMT (Greenwich Mean
Time). When properly implemented, file creation and modification dates are
stamped in a UTC time format. Also, the system clock no longer
changes twice a year but user processes could display a shifted "local view" if
- many systems needed to be up 24/7 (24 hours a day, 7 days a
week) which morphed into 24/365 (24 hours a day, 365 days a year). Think bank
machines and air-line scheduling systems for example.
- computer programs that needed to record elapsed time would
have to compensate for the missing hour when measuring across the change
- possible problem scenario #1:
- Your computer is in location where the time zone changes
between EST (Eastern Standard Time) and EDT (Eastern Daylight-Savings Time)
- You have a user in who creates a file (with a time stamp) at 1:45 AM EDT on
the morning that the clock will fall back.
- 15 minutes later at 2:00 AM (EDT) you move the clock back
to 1:00 AM (EST) by either changing it or rebooting.
- Ten minutes later at 1:10 (EDT) local time, a second user
connects to the system and updates the file in question. This file now has a
creation time stamp that is before the modification time stamp.
- If the second user is smart enough not to mess around with
the original file, then the second file will still have a creation date which is
before the creation date of the first file
- possible problem scenario #2:
- The same computer is on the Internet
- A technical support person FTPs a file from the client system in
Canada to a support system in Germany, works on the file, then FTPs it back to
- The Canadian system clock changes in between FTPs
- Which file is the new one? Are we sure that no German time stamps will end
up on the Canadian system?
- As long as the files in questioned are never accessed by
anyone but the German Tech support person, everything should be all right. But,
if another person becomes inadvertently involved, a real mess could ensue.
Solaris (a flavor of Unix created by SUN Microsystems)
NTP (Network Time Protocol)
Like Telnet, FTP and HTTP, NTP is an Internet
service that has recently started to enjoy an increased popularity, at least it
has with the techies. Basically NTP works something like this...
- an NTP stratum #1 source is a computer "running NTP
software" and is receiving real time information from one of the following:
- an Atomic Clock
- a GPS (Global Positioning System) Radio receiver which
derives it's signal from at least 2 GPS satellites which then derive their
clocks from a military source (usually an Atomic Clock)
- another (peer) stratum #1 NTP server
- any other computer that is running NTP software will have
three types of NTP connections, SERVER, PEER, or CLIENT.
- any time a computer receives time information from any
source, it must do at least 2 things:
- make up to 5 network transactions per query in order to
compute the average transaction time (distance) between itself and it's
next higher stratum source
- it must increment the stratum number so that connected
computers are aware of the quality of the time (a higher number means lower
Caveat: a block diagram used to be here. It was created before Wikipedia
existed. Click the next link here for a better description and diagrams
VAX/VMS System Time
Caveat: most of this stuff is not relevant to
OpenVMS-Alpha or OpenVMS-Itanium
TOY (Time-Of-Year Clock)
Info derived from P.254 of:
Version 4.4 VAX/VMS Internals and Data Structures
(c) 1988 by Digital Equipment Corporation.
TOY Clock Notes:
- based upon a 32 bit unsigned register
- the least significant bit represents a resolution of 10
- initialized to 10000000 base 16 which represents
00:00:00.00 on January 1
- if a booting system sees an empty register, it assumes that
the TOY clock has lost power and ignores it
- counts up, and only holds about 15 months of time (440
days) so requires external information from a file
- to prevent overflow, the system must be either be rebooted,
or the SYS$SETIME system service must be invoked within the first 3 months of the
year from a privileged account (the manager needs to execute the DCL command "SET TIME").
What does this do aside from setting the time? It writes current date
information to files read by the VMS system during boot.
||Time Of Year Clock In Processor Register
||Time Of Year Clock In Console
||Y opt BB
TIMEKEEPING in VAX/VMS
Info derived from P.255-256 of:
When a non VAXcluster VAX/VMS system is booting, SYSINIT runs
routine EXE$INIT_TODR to check the contents of the Time-Of-Year (TOY) Clock to
see if it contains a value greater than hex $10000000.
Version 4.4 VAX/VMS Internals and Data Structures
(c) 1988 by Digital Equipment Corporation.
When the system is either started up or shut down, the $SETIME
routine is called to make sure that both the Time-Of-Year Clock and the
associated date entry in the system image file (SYS$SYSTEM:SYS.EXE) are
accurate. When the value in the Time-Of-Year Clock is too large, its contents
are lowered by one year while the stored value of the system image file are
increased by a year.
- If the test failed, then SYSINIT assumes that the clock
lost power (or had no battery backup) and then prompts the operator
- If the test passed, then SYSINIT runs EXE$GQ_SYSTIME and
uses the value of the Time-Of-Year (TOY) Clock as an offset (in milliseconds)
from a value that is stored in the system image file (SYS$SYSTEM:SYS.EXE) to
determine the correct date and time. This value is converted into a 64 bit
number which represents the number of 100 nanosecond intervals that have elapsed
since 00:00 on November 17, 1858 (the base time for the Smithsonian Institution
astronomical calendar). VMS now uses this internal 64 bit clock.
What's up with
"November 17, 1858" ?
PRODUCTS: OpenVMS VAX, All Versions
OpenVMS Alpha, All Versions
VAX VMS, All Versions
COMPONENT: System Time
SOURCE: Digital Equipment Corporation
Why is Wednesday, November 17, 1858 the base time for OpenVMS (VAX VMS)?
November 17, 1858 is the base of the Modified Julian Day system.
The original Julian Day (JD) is used by astronomers and expressed in
days since noon January 1, 4713 B.C. This measure of time was
introduced by Joseph Scaliger in the 16th century. It is named in
honor of his father, Julius Caesar Scaliger (note that this Julian Day
is different from the Julian calendar named for the Roman Emperor
Why 4713 BC? Scaliger traced three time cycles and found that they
were all in the first year of their cyle in 4713 B.C. The three
cycles are 15, 19, and 28 years long. By multiplying these three
numbers (15 * 19 * 28 = 7980), he was able to represent any date from
4713 B.C. through 3267 A.D. The starting year was before any
historical event known to him. In fact, the Jewish calendar marks the
start of the world as 3761 B.C. Today his numbering scheme is still
used by astronomers to avoid the difficulties of converting the months
of different calendars in use during different eras.
So why 1858? The Julian Day 2,400,000 just happens to be November 17,
1858. The Modified Julian Day uses the following formula:
MJD = JD - 2,400,000.5
The .5 changed when the day starts. Astronomers had considered it
more convenient to have their day start at noon so that nighttime
observation times fall in the middle. But they changed to conform to
the commercial day.
The Modified Julian Day was adopted by the Smithsonian Astrophysical
Observatory (SAO) in 1957 for satellite tracking. SAO started
tracking satellites with an 8K (non-virtual) 36-bit IBM[R] 704 computer
in 1957, when Sputnik was launched. The Julian day was 2,435,839 on
January 1, 1957. This is 11,225,377 in octal notation, which was too
big to fit into an 18-bit field (half of the IBM standard 36-bit word).
And, with only 8K of memory, no one wanted to waste the 14 bits left
over by keeping the Julian Day in its own 36-bit word. However, they
also needed to track hours and minutes, for which 18 bits gave enough
accuracy. So, they decided to keep the number of days in the left 18
bits and the hours and minutes in the right 18 bits of a word.
Eighteen bits would allow the Modified Julian Day (the SAO day) to
grow as large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this
allowed for seven centuries. Using only 17 bits, the date could
possibly grow only as large as 131,071, but this still covers 3
centuries, as well as leaving the possibility of representing negative
time. The year 1858 preceded the oldest star catalog in use at SAO,
which also avoided having to use negative time in any of the satellite
This base time of Nov. 17, 1858 has since been used by TOPS-10,
TOPS-20, and VAX VMS and OpenVMS. Given this base date, the 100
nanosecond granularity implemented within OpenVMS and the 63-bit
absolute time representation (the sign bit must be clear), OpenVMS
should have no trouble with time until:
At this time, all clocks and time-keeping operations in OpenVMS will
suddenly stop, as system time values go negative.
Note that the OpenVMS time display and manipulation routines allow for
only 4 digits in the 'YEAR' field. We expect this to be corrected in
a future release of OpenVMS sometime prior to 31-DEC-9999.
Calendar Kinds - a 10,000 foot (3 km) view
Many ancient peoples, including
Babylonians, Jews, Muslims, and Chinese, based their calendars upon the cycles
of the moon. Some problems with lunar calendars include:
way, the word Month comes from the word Moon (e.g. "Moonth")
- the true year
(the length of time required for the Earth to orbit the Sun) is not a whole
number of lunar months. A 12 month lunar year is too short while a 13 month
lunar year is too long.
- the lunar orbit around the Earth is elliptical rather than circular (and
the ellipse orbits slowly over the course of ~ 19 years)
Solar Calendars (or more correctly, Solar-Lunar Calendars)
Other cultures, such as the Egyptians, based their calendars on
the cycles of the sun. The problem with ancient solar calendars is that the true year is
not a whole number of days.
Click here to examine four popular calendars
(two lunar, two solar)
Egypt ~ 4231-2773 BC
Ancient Egyptians began
numbering their years when the Sirius
(the dog star) rose at the same place as the Sun. The Egyptian calendar was the first
solar calendar and contained 365 days. These were divided into twelve 30-day
months followed by five days of festival. From astronomical
calculations, Sirius and the Sun coincided in 4241 BC and 2773 BC, so either of
these could have served as Egyptian Year 1.
Greece ~ 440 BC
The calendar used by the ancient Greeks was based on the Moon,
and is known as the Metonic calendar. This calendar was based on the
observations of Meton of Athens (ca. 440 BC), who showed that 235 lunar months
made up almost exactly 19 solar years. This 19-year cycle became known as the
Metonic Cycle. However, given a
nominal twelve-month year, and additional lunar months needed to be added to
synchronize the cycle. These were added in years 3, 5, 8, 11, 13, 16, and 19 of
the cycle. (note: year gap sizes are: 2-3-3-2-3-3)
Greece ~ 325 BC
Around 325 BC, Callippus modified the calendar by noting that
four 19-year Metonic cycles with 940 months were very close to 27,759 days. This
is called the Callipic Cycle.
Hipparchus noted that an even more accurate cycle (now called the
Cycle) consisted of four Callipic Cycles less a day, in which ((4 x 27759)-1)
days were very nearly 3760 months. However, neither system was widely used. A
lunar-based calendar is still used by some religious sects to determine
holidays. Easter, for instance, generally occurs on the first Sunday following
the first Full Moon after the Vernal Equinox, although the actual scheme is a
bit more complicated still (Montes).
Greece ~ 200 BC
In 1901, a planetarium-calendar device, now called the Antikythera
Mechanism, was recovered from a
shipwreck circa 65 BC off the Greek island of Antikythera. It is believed to have been designed by either
Hipparchus (190-120 BC)
(287-212 BC). By turning a handle, three displays are put into motion.
Single Dial Side
- Planetarium: Displays the
position of the Sun, Moon, and five planets (Mercury, Venus, Mars, Jupiter and
Saturn) are displayed.
- The Moon pointer changes speed reflecting the moon's elliptical
- The individual planetary pointers will occasionally move
backwards reflecting retrograde motion
- Dual Dial Side
- Displays 235 lunar months over 19 years
- The Callippic Dial is the left secondary upper dial, which
follows a 76-year cycle, quadrupling the Metonic dial
- The Olympiad Dial is the right secondary upper dial for
determining the dates of the Olympic games
- Eclipse Predictor: both lunar and solar
The Pragma of Rome
Rome - 753 BC
Ancient Rome's calendar was neither lunar or solar, it was
agricultural. It consisted of ten lunar months, beginning with the spring moon
in March and ending 304 days later in December (the tenth month). The period between December and
March was disregarded since no agricultural activity was possible during those
60 winter days. In keeping with an ancient custom, each month was divided into
three sections known as Kalends, Nones and Ides, each of different lengths. The
word Kalends, meaning a "calling" or announcement of a new month, gave us the
word calendar. The Nones was nine days before the Ides. Since this Romans used
inclusive counting, this day was always on the 5th or 7th of the month. The
start of the calendar was chosen every year so that the Ides (either the 13 or
15 day) of each month would always land on a full moon. Months in this calendar
consisted of only odd numbered days (29 or 31) because superstitious Romans
tended to avoid even numbers whenever possible.
Rome - 304 BC
Proposed by Numa Pompilius (reign 715-673 BC) but not published
until 304 BC (this date is in dispute), the number of months was increased from
ten to twelve by adding January and February.
(January comes from the two faced god Janus who simultaneous looks ahead and back). The months were still lunar in
character, their lengths alternating between 29 and 30 days. This gave the year
354 days but as the total was an even number and to the Romans this was unlucky,
an extra 355th day was added at the end of the year. After being advised by his
astronomers that the extra 355th day would not be sufficient to agree with the
seasons which were important to both agriculture and military operations, Numa
inserted an additional thirteenth month every two years, calling it Mercedonius
(from the Latin word for wages, indicating that it meant extra remuneration).
This "remunerative" month of 22 or 23 days was arbitrarily thrust into the
calendar toward the end of February, after the 23rd, when the newly inserted
month began. When it was finished, the remaining five or six days of February
carried on. Of all the complicated man-made calendar adjustments in history,
this was certainly the most fantastic.
Rome - 45 BC (the calendar moves to 365.25 days)
Proposed by Julius Caesar in 45 BC and slightly modified
thereafter by Caesar Augustus, this calendar agrees with the
Egyptian solar calendar and even implements a leap year (by adding an extra day
to February) every 4 years so the calendar is synchronized with the heavens
months of Quintilis (fifth) and Sextilis (sixth) were renamed to July (after
Julius who was born in that month) and August (after Augustus). January was made
the first month so August would become the 8th month (because Augustus' given
name was Octavian). This is why September (sept=7) through to December (dec=10) appear to be
Solar Calendar Before Julius Caesar
(requires a leap month
every two years;
February is smaller at this time)
Martius (March )
Aprilis (April )
Maius (May )
Junius (June )
Quintilis (July )
Sextilis (August )
7th month (September)
8th month (October )
9th month (November )
10th month (December )
11th month (January )
12th month (February )
Mercedonius (wages )
Solar Calendar After Julius Caesar
(requires a leap day
in every fourth
Martius (March )
Aprilis (April )
Maius (May )
Junius (June )
Julius (July )
Augustus (August )
9th month (September)
10th month (October )
11th month (November )
12th month (December )
1st month (January )
2nd month (February )
1+ 28 days
Nicaea - 325 AD
Easter was originally linked to Passover, but in the year 325 AD,
the council at Nicaea (under the Roman emperor Constantine) decided that Easter would be celebrated on the first
Sunday following the first full moon, on or after the vernal equinox (the
passing from winter into spring). In the year 325 AD, the vernal equinox was
assumed to be fixed at March 21.
Rome - 523 AD (years change from AUC to
At this time it was customary to count years since the founding
of Rome (ab urbe condita or AUC) and "the church was using an Easter calculation
algorithm which was about to come to an end". Around 523 AD, the papal
chancellor, Bonifatius, asked monk
(Denis the Little) to devise a new method to calculate Easter. Information from
seem to indicate that
Dionysius was aware that a 532 year variation 1 of the
Metonic Cycle was conveniently restarted near the birth of
Christ. Since only pagan cultures celebrated birthdays, Dionysius Exiguus was
more concerned with the mathematical beauty of the
Metonic Cycle than determining the birthdate of Jesus Christ. So his main
claim to fame was to change the numbering of years from AUC to a
date near the birth date of Jesus Christ (Anno Domini, "in the year of our
Lord") only for the purposes of publishing a new Easter algorithm.
The variation of the Metonic Cycle works like this:
The beginning of this cycle falls on January 754 AUC which
Dionysius renamed to 1 AD ("anno domini" meaning "year of our Lord").
- 19 years (the Metonic Cycle)
- 4 years (the Callipic Cycle
helps to account for leap years)
- 7 days in a week (Easter must fall on a Sunday)
532 years = 19 x 4 x 7
- According to the Gospel of Luke (3:1 & 3:23) Jesus was
"about thirty years old" shortly after "the fifteenth year of the reign of
Tiberius Caesar". Tiberius became emperor in AD 14. If you combine these numbers
you reach a birth year for Jesus that is strikingly close to the beginning of
our year reckoning. This may have been the basis by Dionysius' argument. (on
the flip side, the Gospel of Luke mentions a Roman Census which historical
records say is the
Quirinius which occurred in 6/7 AD).
- The Gospel of Matthew tells us that Jesus was born under
the reign of king Herod the Great
Since Herod died in 4 BC. It is likely that Jesus was actually born between 5 BC
and 7 BC.
- Today it is commonly believed that Dionysius made a
mistake in determining the exact date of Christ's
birth but this was not his intention. In 523 only pagans
celebrated birthdays meaning that those Christians had no intention of celebrating Christ's birth.
Rome - 1582 AD (the calendar moves to ~ 365.2425 days)
Neapolitan astronomer Aloysius Lilius noticed that the Julian
calendar (which had a leap year every 4 years) was too long by almost 11 minutes per year
which translated into a discrepancy of approximately 9.5 days by the year 1582. In order to make the calendar synchronize with
the heavens, he suggested that centuries which are evenly divisible by 100
should not be leap years except those which are evenly divisible by 400.
Easter was originally linked to Passover, but in the year 325 AD
at the council at Nicaea, it was decided that Easter would be celebrated on the
first Sunday following the first full moon on, or after, the vernal equinox (the
passing from winter into spring). In the year 325, the vernal equinox was
assumed to be fixed at March 21.
Due to inaccuracies in the calendar, by the 16th century the
vernal equinox was occurring on March 11. This caused problems for the church in
Rome because most Christians outside of Rome were using the date "March 21" to
calculate the day of Easter rather than the "vernal equinox" event. (sometimes
bad weather combined with a lack of local astronomers made "the calendar option"
the only choice). This had the effect of pushing the day of Easter celebration
closer to the summer months.
Pope Gregory XIII assigned the problem to a Jesuit astronomer
named Christopher Schlussel (a.k.a. Clavius) who suggested that the
Easter/equinox problem could be solved by removing 10 days from
the current year (shifting the vernal equinox back to March 21) but from that
time forward the Christian world should adopt the idea proposed by Aloysius Lilius. The plan was approved by Pope Gregory approved
the plan in 1582 and decreed that October 4 was followed by October 15. The
peasants revolted thinking that their lives had been shortened by that much. The
new calendar was named the
Gregorian Calendar after the pope who approved the
This so-called "continental calendar" wasn't adopted by England,
or its colonies including America, until 1752. At that time, 11 days
needed to be removed. (10 for the original correction, 1 for the century
- The Earth requires 365.2425
mean solar days
(averaged over 4 years) for one
revolution around the sun, not 365.25 as is commonly believed
- This difference translates into ~ 648 seconds per year which needed to
be removed to correct for Easter as defined in 325 AD
seconds per year
Computer Calendar Bugs
Year 2000 Problem (a.k.a.Y2K Problem)
Part 1: Short Field
Storage (a.k.a. lazy programming)
God hits the RESET button.
(but the problem was caused by man)
When dealing with dates, many programmers decided to only code for,
and store, the least two significant digits of the year. This started with early
mainframe programmers (1950s-1970s) who only had 80 columns of storage on each punched
card. This tradition was continued on minicomputers (1970s-1980s)
and PCs because memory and storage were still very expensive. There is no need to do
Fact: In 1989 a woman in who was born in 1884 was placed on a
Kindergarten enrollment list because her 2-digit birthday (89) indicated that
she was 5 years old.
Imagine the problems on January 1, 2000 when automated programs...
Stuff (cheap vs. lazy)
- decide to purge seemingly stale records
- decide to compute
negative interest values
- decide to lock-out seemingly expired credit cards?
Although most currently supported operating
system software has been fixed, much application software, and firmware
associated with old harware, are still broken. Unsupported software (like MS-DOS) and
obsolete firmware (like PC BIOS before 1995) will probably never be fixed.
Furthermore, application software that makes direct BIOS calls to check the date
instead of calling a similar routine in the operating system is at great risk
since the application software will only fail on certain platforms.
If (for productivity reasons) your users only enter 2 digit years,
programmers should translate these dates to 4 digits for storage. Failure to do
this means this problem will be back in the year 2100.
Part 2: Is 2000 AD a Leap
||divide by 4
||If a year is evenly divisible by 004,
then that year is a leap year.
Using this rule, 2000 AD is a leap year.
|Everyone knows this rule
||divide by 100
||If a year is evenly divisible by 100,
then that year is not a leap year.
Using this rule, 2000 AD is not a leap year.
|Many people seem to
know this exception
||divide by 400
||If a year is evenly divisible by 400,
then that year is a leap year.
Using this rule, 2000 AD is a leap year (which is true).
|Few people seem to know this
to the exception
||divide by 4000
||If a year is evenly divisible by 4000, then that year is not a leap year
Some Unix systems and some "C" programs will
hit a wall on Saturday 2004-01-10. The reason for this is the fact that these 32
bit clocks record the number of seconds that have elapsed since 1970-01-01
(start of the Unix epoch).
In some instances vendors only used 29 bits which means that
we will experience (2^30 = 1,073,741,824 seconds) ~34.025 years of range before
It's only 10 years since Y2K and some bozo programmers didn't learn the
lesson. Now we've got problems with portable devices
running WindowsCE along with other stuff.
(and Y2106 Problem)
Many Unix systems and/or "C" programs using the
"time_t" or "time_b" structures will hit a wall on Monday 2038-01-18. The reason
for this is the fact that these 32 bit clocks record the number of seconds that
have elapsed since 1970-01-01 (start of the Unix epoch).
If the 32-bit clock location was treated as a signed
integer, then there are only (2^31 = 2,147,483,648 seconds) ~68.051
years of range before we overflow. 1970 + 68 = 2038. BTW, the exact rollover
date is: 3:14:08 AM (GMT) on January 19, 2038
If the 32-bit clock location was treated as an unsigned
integer, then there are only (2^32 = 4,294,967,296 seconds) ~136.103
years of range before we overflow. 1970 + 136 = 2106.
- I'm sure that "C" libraries and related OS calls will be
modified to either 32-bit unsigned or
64-bit before 2038. According to this article,
Linux already has which is probably one reason why it is found in the
datacenters of most banks and insurance companies. However, egotistical programmers who prefer to do
their own thing rather than call the OS are sure to get stung by this one.
- I wonder how much embedded "C" software will still be
working in bank machines, credit card readers, and PC BIOS firmware?
It was suggested by the astronomer John Herschel
(1792-1871) among others, that a better approximation to the length of the
tropical year would be 365 x 969 / 4000 days = 365.24225 days. This would
dictate 969 leap years every 4000 years, rather than the 970 leap years mandated
by the Gregorian calendar. This could be achieved by dropping one leap year from
the Gregorian calendar every 4000 years, which would make years divisible by
4000 non-leap years. This rule has, however, not been officially adopted.
Advice to System Managers and System
- Never take chances. Always call operating system routines
rather than doing the date calculations yourself. The operating system software
designers have consulting astronomers on staff to assist in this sort of thing.
They will almost always do a better job of this stuff than the little guy.
- BIOS routines are written in firmware. Operating Systems
are written in software. Since the BIOS routines may be broken but the operating
system may be fixed, never call the BIOS directly, Always call the operating
For some reason, it is currently considered COOL to make one the following
What many people fail to realize is that, in most cases, new
software can make up for inadequate hardware. Whenever
possible, 32-bit Windows will replace calls to 16-bit BIOS routines with 32-bit
routine for your clock chip can also be replaced but only if you have installed new
- I'm not going to upgrade to Windows 95. Windows 3.11 is
good enough for our company.
(Bill Gates isn't going to squeeze me for some
feature that I don't need)
- I'm not going to upgrade to Windows 98. Windows 95 is good
enough for our company.
(Bill Gates isn't going to squeeze me for some feature
that I don't need)
- I'm not going to upgrade to Windows 2000. Windows NT4 is
good enough for our company.
(Bill Gates isn't going to squeeze me for some
feature that I don't need)
Date/Time Stamps (and displays)
How many times have you seen a date of the form 5/10/97 and
thought to yourself "is that May 10th or October 5th?". It seems that Americans
prefer mm/dd/yy while Brits prefer dd/mm/yy
and the remainder of Europe prefers yy/mm/dd. Canadians are so
confused they'll use anything. Does anyone know what this 05/06/07 means?
IMHO, the whole world should start to use a variation of the
metric format ISO-8601 (sometimes called Star Trek Time) which
has the following rules:
1. the most significant field (year) appears first while the
least significant field (day) appears last.
Here are a few examples for May 10th, 1997:
Similar to the odometer in your car.
2. By removing any slashes, everyone will automatically know
which time format is being used. The lack of slashes will also allow the string
to be used in computer file names. Some computer file systems (Unix) will allow
more than one period in the file name.
3. Leading zeros must always be used to pad fields (e.g.. month
must be 05 not just 5)
Format #1: (Recommended)
970510 (should only be used on print outs)
19970510 (can also be used internally )
970510.2359 (should only be used on print outs)
19970510.2359 (can also be used internally )
970510.235959 (should only be used on print outs)
19970510.235959 (can also be used internally )
+--------- indicates a switch from date to time
970510:2359 (should only be used on print outs)
19970510:2359 (can also be used internally )
970510:235959 (should only be used on print outs)
19970510:235959 (can also be used internally )
970510:235959.10 (should only be used on print outs)
19970510:235959.10 (can also be used internally )
| +--- indicates a switch to fractions of a second
+---------- indicates a switch from date to time
When numeric strings are used in naming data or log files, you
will find that sorted directories will be a little more ordered and that file
purges are a little safer since you can type:
rm 199705* to delete all May 97 files in Unix
del 199705*.* to delete all May 97 files in DOS
del 199705*.*;* to delete all May 97 files in OpenVMS
It's too bad that so many people remain superstitious because a 13-month
calendar would be more efficient.
7 days * 4 weeks = 28 days per month
28 days * 13 months = 364 days per year
Since the length of a year is 365.24 days, the 13th month would have 29 days except on leap year when it should have 30.
With a standard 28 days per month it would be easier for businesses and
governments to do monthly economic forecasts. Since western workers usually skip
between 2-4 work days near the end of December (Christmas, Boxing Day, etc.),
this month would be the best candidate to extend by one or two days.
The 13 month calendar would be better for Canadian bank employees who only
get paid twice per month or landlords who only get paid once per month.
DST07 (Daylight Savings
Back in 2005, the Bush/Cheney Administration (USA) thought they could save some energy
starting in 2007 by shifting the beginning of DST from the first Sunday in April
to the second Sunday in March (advanced by 3 weeks). They also decided to end
DST one week later by moving DST from the last Sunday of October to the first
Sunday of November (delayed by one week).
Now you would have thought that the computer industry would have learned their
lessons after Y2K, but they didn't. To make matters worse, rather than keep DST
rules in the host OS, we now also need to patch:
- Java Libraries
- C/C++ Libraries
- Oracle Database
- Some Messaging Systems with links into PDAs like the Blackberry
- Some Application Software (containing baked-in DST code)
To add insult to injury, since those Y2K days many North American computer
professionals have been let go and their jobs have been outsourced to India
where people don't observe DST because they live so close to the equator. Oh
well, just another mess linked to the effects of extreme market capitalism.
To the best of my knowledge, no RTC (real time clock) chips save the
time zone. This means that just after a computer's local time has changed, a BIOS
call must be made to save the new time to the RTC chip. Failure to do this means
that a rebooted computer may come up with the wrong time. For the past 20
years most UNIX systems updated the RTC from root's crontab by calling
/usr/sbin/rtc every morning in APRIL and OCTOBER like so.
% crontab -l
# This is root's crontab
# The rtc command is run to adjust the real time clock if and when daylight savings time changes.
10 3 * * 0,4 /etc/cron.d/logchecker
10 3 * * 0 /usr/lib/newsyslog
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
# run task every day in April at 3:01 AM
1 3 * 4 * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
# run task every day in October at 2:01 AM
1 2 * 10 * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
To fix your system you'll need to implement one of the following two
suggestions. If you don't know how to make these changes then you'll need to
contact your local UNIX guru.
# The two red lines above could be replaced with the following (suggestion #1 - preferred)
# run task every day at 3:01 AM
1 3 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
# The two yellow lines above could be replaced with the following (suggestion #2 - alternate)
# run task every day in March + April at 3:01
1 3 * 3,4 * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
# run task every day in October + November at 2:01
1 2 * 10,11 * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
You should to stick with database support
A good way to avoid future date-time problems is to stick with products with
built-in support. For example, there a datetime object built into most
databases. Look at these two examples from MySQL + MariaDB. The second example
is a hack to magically return the data in ISO-8601 format
MariaDB [(none)]> select now();
| now() |
| 2018-10-22 14:13:23 |
1 row in set (0.00 sec)
MariaDB [(none)]> select now()+0;
| now()+0 |
| 20181022141330 |
1 row in set (0.00 sec)
Date + Time Formatting
Kitchener - Waterloo - Cambridge, Ontario, Canada.