5 ms·

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 d

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.

Gigablah 14y ago
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 14y ago
  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.
fdr 14y ago
> 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.html 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 14y ago

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 14y ago
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.

fdr 14y ago

> 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.html 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.