Anyway, it was a ‘Happy Birthday‘ email, and no, my birthday is not the January, 1st.

It’s very unlikely that I entered 01/01 as my DOB: I try not to tell it to online stores when the field is not required; even when it is I prefer to enter 02/29 to minimize the number of such automated HB congratulations.

So it got me thinking: why on earth would their database contain 01/01 as my DOB?

My best guess is that they are storing date of birth as a unix timestamp. And at some point the value I provided (NULL) got converted to 0 (zero).

And zero seconds since the Epoch means 01/01/1970: so, their software decided I just turned 45 and sent me a happy birthday email (I didn’t think it was possible, but my opinion about that particular store got worse).

What lessons should developers learn from this story?

1. Never use TIMESTAMP when you can use DATE data type. They are different, and date of birth is definitely a DATE.
2. Do not confuse NULL and zero (or empty string). NULL is a special value, meaning ‘NOTHING’. There are cases, when it’s the same as zero (e.g.: number of items purchased), but generally it’s not the same (as in my example with non-entered DOB).
3. Use DEFAULT values properly. 0 and NULL are not necessary the same.
4. Treat data carefully during upgrades/conversions. I’m not sure if the DOB field was there when I was registering at the website, but it could be introduced in the database later – and all old records may have got their values for DOB field set to 0 instead of NULL.

In my last guess is true, I’m not the only one who got that stupid ‘Happy Birthday’ notification when we should have received ‘Happy New Year’ notification instead.

Happy New Year to all (if any) readers of this blog!

First solution, hacker-style (source):

(31 - (($m - 1) % 7 % 2) - ((($m == 2) << !!($y % 4)))) ?>

This solution doesn’t work properly for years divisible by 100, and non-divisible by 400 (years 1900 and 2100 are not leap)

Second solution, canonical:

date("t",mktime(0,0,0,$m,1,$y));

This solution works only for dates which can be presented as unix timestamps, therefore it’s not good (depends on PHP version and OS.)

Third solution, proper:

function days_in_month($y,$m)
{//by val petruchek http://petruchek.com
    $d = 31;
    while(!checkdate($m,$d,$y)) $d--;
    return $d;
}

This solution is based on built-in PHP function checkdate() which validates Gregorian date without unix timestamps.