|Dates Are Difficult|
|Written by Mike James|
|Thursday, 29 August 2019|
Page 3 of 3
You may have encountered the idea of the "financial year" or 360 day year and wondered why.
Before the days of the computer, finding the number of days between any two given dates was a difficult problem. To make things easier the financial world used a calendar that assumed that every month had 30 days, making the financial year 360 days.
So if you borrowed money for two months the idea was that you would pay 60 days interest no matter which months were involved. Of course how to actually do this calculation is something that has to be agreed by all parties before the transaction and there are different ways of doing it. You can still compute date differences using the 360-day financial year in most spreadsheets and Excel, for example, will allow you to specify that either the US or the European method.
There are lots of other examples of simplifications of calculation in the financial world that were introduced to make the sums easier. You generally don't need them today but you will still encounter them and if you have to deal with old transactions you may have to work with them.
Date Serial Numbers
However, today there is little reason to use a financial year as date/time data types generally store the data as the number of days from some fixed point and this means we can work out the number of days between any two dates exactly.
The way that this works is that dates and times are stored as the time interval from a given date - either in days and fractional days or as the number of seconds or some other unit.
That is when you enter a date in day, month, year format it is automatically converted to the number of days or time from a fixed date – this is often called a date serial number.
Excel, for example, uses 1 January 1900 as day 1 but it also supports an alternative system that takes 2 January 1904 as day 1 to remain compatible with older versions and the Mac version of Excel.
Different systems use dates to calculate the interval from. For example, the Unix time and date system works by simply counting the seconds since the 1st of January 1970 - which is known as the Unix Epoch.
So using this simple idea we have a completely foolproof way of handing dates and times and there is no need for the financial year or any simplifications.
If you want to work out the difference between two dates simply convert them to date/time serial numbers and subtract. For example in Excel you would use
to work out the number of day between the two dates. You can add a number of days to a date in the obvious way:
adds 10 days to the date and this works even if it rolls over a month or year boundary.
Things are more difficult if you want to add a month or even a year to a given date because these units don’t correspond to a fixed number of days.
If your intention is to increment the month number by one rather than move on 30 days say then you generally have to resort to complicated methods that convert the date to day,month,year format, add one to the month and convert back to date serial number.
Some languages, Visual Basic for example, do provide functions that will add a month or a year to the date specified (lookup the DateAdd and DateDiff functions).
What is amazing is that even after all this work we can still make a mess of working with dates. All you need to do is to try and tackle a problem that involves a time that takes you past midnight to see what I’m getting at!
If you think that the millennium bug, when we all thought that the computer world would come to an end when the year date rolled over, was the last date crisis then you need to think again.
This particular problem was caused by many programs, not expected to last to the turn of the century, simply not storing the century part of the date and was entirely obvious and easy to avoid. There are much more subtle ways of making a mess of dates and times that are just as serious and much more difficult to fix.
By the way, the next big date bug is expected in 2038 when the Unix 32-bit time stamp rolls over to 0. Given that the Unix time and date system works by simply counting the seconds since the January 1st 1970, using a 32-bit integer sets a limit for the most future date it can handle. The largest positive 32-bit integer represents a date of Tuesday, January 19, 2038 - and after this time all Unix time stamps will roll over and look like dates back in 1901.
A Unix date/time is a signed 32-bit number, so you can use negative seconds, which give dates and time before 1970. Using the largest 32-bit negative number gives a date of Friday 13th in December 1901 as the earliest Unix date. So if you try to book something in 2038 be prepared for it to happen in 1901.
What Programmers Know
* Recently revised
or email your comment to: firstname.lastname@example.org
|Last Updated ( Monday, 13 April 2020 )|