Here’s a modelling scenario that crops up on many occasions in software systems.

Today is wednesday. The friendly neighbourhood HR person is updating the HR system. She needs to record the following information.

Last thursday, Bob from Treasury received a pay rise, commencing next friday.

It’s now monday almost 2 weeks later, the business day after next friday. Friendly neighbourhood HR person is told of a mistake with Bob’s pay rise. She needs to record the following information.

The pay rise recorded for Bob 2 wednesdays ago that he received 3 thursdays ago that commenced last friday was wrong. It should have been backdated to the beginning of the month, 5 fridays ago, not last friday.

Developers and their software can get in an awful mess if sufficient thought is not given to the many dimensions of time. In this example a robust system would have recorded the following:

• The time the initial entry was made by FNHRPerson.
• The time the pay rise was given to Bob.
• The time the pay rise took economic effect.
• The time the entry was modified.
• The new time the pay rise took economic effect.

It might also need to answer questions like, ‘when does Bob’s pay rise take effect?’ and ‘as of the day before yesterday, when did you think Bob’s pay rise took effect?’.

There’s a whole other side to this story with respect to calculating how much money had changed hands and the correction required in light of the new date data. But that’s another dimension altogether.