Date pitfalls

Wrong assumptions

Time and date are not simple concepts: weeks do not fit in months or years, every month has a different number of days and everywhere around the world people keep a different time. Even if you keep that in mind, there are some easy assumptions which may prove wrong. Most of the time you realize that once your code turns out to be buggy. Here are some assumptions about dates which are not always true:

Days have 24 hours

Some countries have daylight saving time, which means that the clock is shifted an hour ahead in spring and an hour backward in autumn. When the clock is shifted forwards, the day contains one hour less. When the clock is shifted backwards, the day has one hour more. This means that in the spring a day can have 23 hours and in the autumn a day can be 25 hours long.

This shifting of the clock has some more consequences. When the clock moves forward from 2:00 AM to 3:00 AM, it means the time between 2:00 and 3:00 did not occur. If your program does something every day at 2:30 AM, it may skip its task the day the clock moves forward. Similarly, if the clock moves backward, the same time occurs twice on a day. Your task may be executed twice.

When working with dates and times, keep an eye on DST.

Every fourth year is a leap year

There are on average 365.2425 days in a year. A leap year every four years adds a quarter of a day every year, giving 365.25 days. This is too much by .0075 days, or three days every 100 years. That is why years dividable by 100 are not leap years, except if they are dividable by 400.

Of course, this exception to the rule applies only once in 100 years, so it is not something you come across often. On top of that, the last twist of the century we had (the year 2000) was dividable by 400, so a leap year after all.

Every month has between 28 and 31 days

The current calendar we have in Western countries, the Gregorian calendar, was not always used. Before the year 1582, most countries used the Julian calendar, which was 10 days off at that time. This means that when a country switched from the Julian to the Gregorian calendar, is lost 10 days. The next day after Thursday 5 October 1582 was Friday 15 October 1582.

To make things even more complex, different countries adopted the Gregorian calendar on different dates. Parts of Europe switched in 1582. Great Britain switched in 1752 and the former USSR in 1922. Because of state borders have also changed in the meantime, the transition date may be different for different places in the same country.

If you are using dates before 1926, think about which calendar you want to use.

Implementation pitfalls

In Java, months start from 0

The Date and Calendar class take a month parameter which is zero-based. That means that new Date(2009, 01, 01) indicates a date of the first of February instead of the first of January.

Date methods may do timezone conversion

In Java, a new Date is by default created in the current timezone. However, the getTime() method returns the number of milliseconds since 1970 GMT. This means you can not use the result of getTime() as an absolute value, because it is in a different timezone.

Date ranges are limited

In some languages, the range of the date type is so limited that it is annoying. For example, PHP stores the number of seconds in an 32 bits int, giving a range between the year 1901 and 2038. Bad luck when coding your mortgage calculator or your webpage about historic events in PHP.

About time zones

If you use times or dates with timezones in your program, you should make sure that every time or date has a timezone. A time without timezone is meaningless if you want to compare it with a time which has a timezone.

About week numbers

According to ISO 8601, the first week of the year is the week with 4 January in it, or the first Thursday. In the UK and the US, the first week is the week with 1 January in it, or the first Saturday. However, in the UK weeks start at Monday and in the US at Sunday.