[andjones]

This article seems to be picking on date / time manipulation within PHP. I don't see a database in use.

The title should say something about PHP not handling date/time correctly. This is nothing new.

I'm not positive if MySQL, PostgreSQL, Oracle, or similar would perform the same date and time manipulation correctly. However, I know from personal experience that MySQL handles date/times more consistently than PHP.

I'm curious to see if someone with more knowledge than myself can chime in on the issue.

[fdr]

> I'm not positive if MySQL, PostgreSQL, Oracle, or similar would perform the same date and time manipulation correctly. However, I know from personal experience that MySQL handles date/times more consistently than PHP.

Postgres boasts some very pedantically excellent timestamp and timezone support. If there is a bug, it will be rectified in all possible haste once reported.

For example, from http://www.postgresql.org/docs/9.2/static/functions-datetime...:

    The first century starts at 0001-01-01 00:00:00 AD, although they
    did not know it at the time. This definition applies to all
    Gregorian calendar countries. There is no century number 0, you go
    from -1 century to 1 century. If you disagree with this, please
    write your complaint to: Pope, Cathedral Saint-Peter of Roma,
    Vatican.

    PostgreSQL releases before 8.0 did not follow the conventional
    numbering of centuries, but just returned the year field divided
    by 100.

[Gigablah]

From the article: "Databases rarely handle timezones, daylight savings time and rule changes correctly, so avoid the database specific functionality all together."

The article isn't "picking on" PHP, it's highlighting that timezone rules are constantly changing (which is not a language-specific problem) and details how to handle them (e.g. using an extension that's updated more frequently).

[gaius]

Date/time handling code is pretty tricky - not leveraging what's in your platform is going to suck up a lot more time than you think. As for "databases rarely..." the answer to that is not to hand-roll your own wheel in PHP but to get a better database.