Financial Calculations

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

Date(1/5/1985)-Date(10/3/1950)

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:

Date(1/5/1985)+10

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).

Date Bugs

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.

Why 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.

Leap Year Gotcha for Azure

Speed dating - the art of the JavaScript Date object

Calculating with dates in Excel 2003     

Monthly Calendar

Cartoon - Why 1970? or Dating Troubles

The Mod function

• Mike James is the author of Programmer's Python: Everything is an Object published by I/O Press as part of the  I Programmer Library. With the subtitle "Something Completely Different" this is for those who want to understand the deeper logic in the approach that Python 3 takes to classes and objects. His latest book is The Programmer’s Guide To Theory: Great ideas explained.

What Programmers Know

Contents

1. The Computer - What's The Big Idea?*
2. The Memory Principle - Computer Memory and Pigeonholes*
3. Principles of Execution - The CPU
4. Assemblers and assembly language*
5. The Essence Of Programming
6. Variables - Scope, Lifetime And More*
7. Binary Arithmetic
8. Hexadecimal*
9. Binary - Negative Numbers*
10. Floating Point Numbers*
11. Inside the Computer - Addressing
12. The Mod Function
13. Recursion
14. The Lost Art Of The Storage Mapping Function *
15. Hashing - The Greatest Idea In Programming
16. Advanced Hashing
17. XOR - The Magic Swap*
18. Programmer's Introduction to XML
19. From Data To Objects*
20. What Exactly Is A First Class Function - And Why You Should Care*
21. Stacks And Trees*
22. The LIFO Stack - A Gentle Guide*
23. Data Structures - Trees
24. Inside Random Numbers
25. The Monte Carlo Method
26. Cache Memory And The Caching Principle
27. Data Compression The Dictionary Way
28. Dates Are Difficult*
29. Sequential Storage*
30. Magic of Merging*
31. Power of Operators
32. The Heart Of A Compiler*
33. The Fundamentals of Pointers
34. Functional And Dysfunctional Programming*

* Recently revised

 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Coded Easter Eggs A software Easter Egg is an intentionally hidden novelty or message concealed for personal reasons within a computer program or application.  We take a look at its history and original motivation [ ... ] + Full Article

XOR - The Magic Swap We all know that if you want to swap the contents of two variables you need a third temporary variable to do the job. It's like swapping the contents of two mugs using a third to hold the contents of  [ ... ] + Full Article

Other Articles Data Structures Part II - Stacks And Trees Programmer's Guide To Theory - Practical Grammar Principles Of Execution - The CPU Programmer's Guide To Theory - Splitting the Bit IP Addressing and Routing Fractal Image Compression What If Babbage..? Programmer's Introduction to XML

<ASIN:0879304960>

<ASIN:0521702380>

<ASIN:0380793245>

<ASIN:0070211205>

<ASIN:0486409139>

<ASIN:0380793245>

<ASIN:048641146X>

<ASIN:0521702380>