Seriously, WTF?

Luis Motta Campos luismottacampos at
Thu May 8 09:33:43 BST 2008

Toby Corkindale wrote:
> Sadly, I'm stuck on the abhorrent-in-the-eyes-of-all 4.0.xx versions;
> I want to try and remove obstacles to upgrading one day when the
> higher powers allow though, and so using TIMESTAMP is ruled out as
> its behaviour and format changes between almost every version of
> 3/4.0/4.1/5.0/etc! I wish they'd fixed the DATETIME DEFAULT issue in
> 5.0 actually, as it might have been a help to push towards upgrading
> to it.

Toby, I recommend you to seriously consider using strings or integers
(depending on your range and precision needs) to hold dates, and relay
on converting them to proper date types at the application side.

MySQL DATETIME ranges are minimalistic and doesn't allow much more than
conventional commercial applications. Even some complementary retirement
funds have problems managing data without using out-of-bound dates.

I believe that this can be properly addressed into
DateTime::Format::MySQL, by specializing the class to convert {from,to}
{strings,integers} instead of the conventional DATETIME data type.

[REPLACE INTO 'feature']
> It's like they realised that they didn't have decent transaction
> support, so made an atomic delete/insert method instead. And then
> poor fools used MySQL, and used these non-standard commands as the 
> only way to do things, and then poor fools like me came along and had
> to support it later.

I agree, it doesn't sounds sensible. I hope that being part of the Sun
world help changing this (I hope that Sun plans their software better
than MySQL does).

I would rather put the database in STRICT MODE, and never ever allow
people to use that. If they already used it, arrange a test for the
system and set removing this kind of code as a short-term goal for the
maintenance team.

My twoppence.
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}

More information about the mailing list