dates before 1970

By tomamic on 26 Jan 2006 at 15:27 UTC

Minor issue:

The function node_validate in node.module doesn't allow nodes to have a negative 'created' field.
It's very limiting for my project, and I don't understand the motivation.

Couldn't the following line...

if (strtotime($node->date) <= 0) {ù

... be changed to

$created = strtotime($node->date);
if ($created === -1 || $created === FALSE) {

Not sure I should have posted here... but thank you!
Ciao. Mic

Comments

There is no such thing as a

sevo commented 26 January 2006 at 15:45

There is no such thing as a date before 1970 that can be stated as a Unix timestamp - the latter being either unsigned or (in old implementations) undefined in its behaviour with negative values. That is, abusing the node creation timestamp to refer to dates older than the timestamp epoch will sooner or later raise hell, even if you bypass the checks in node_validate.

You should add a custom field with a more appropriate type (the backend databases have more flexible date/time data types) if you need to refer to historical dates.

Sevo

In reality... there is! :)

tomamic commented 26 January 2006 at 17:00

http://en.wikipedia.org/wiki/Unix_epoch
http://www.php.net/manual/en/function.strtotime.php

I don't think a negative timestamp is an abuse, even if I would have preferred an ansi date.
Talking about POSIX in general... you're right. But this is not POSIX, the drupal db schema allows negative values, as well as php5. If one has php4... ok, he won't be able to use negative values. I'll see a reason there :)

Anyway, this is the wrong place for my post. Sorry!
I've added an issue about node.module.

This is the only article

Rhino commented 25 April 2008 at 10:28

This is the only article that I can find discussing "negative time", has there been any progress on this? I'm creating a library where nodes that contain reference material is dated at the time the material was created rather than when I bother to post this to my drupal site. Some material was created way back in 1948. Should I have chosen another CMS? What is the reason for choosing unix time?

Unix timestamps are pretty

macgirvin commented 25 April 2008 at 12:44

Unix timestamps are pretty well embedded into Drupal, and I don't see much way around it on the short term. If you filed an issue now and got it fixed in 7.x (unlikely one could get it through the system that quickly) it would still be a year or two before you'd see a workable product with all your favorite modules upgraded to use it.

I can envision creative uses of the Date module along with the CCK that you can do today, but these still won't give you the same level of query integration as a native MySQL datetime field.

I'm not sure what other CMS to suggest, though this may be your best choice for historically dated objects. I wrote my own CMS at one point that is free from these limits so I know that such a thing exists.

I believe the reason for using Unix time (IIRC) had to do with a database performance issue. Personally I'd much rather have human readable timestamps in my database, and live with the performance hit or gain it back through improvements elsewhere. There are occasions when you need to find out everything that happened on your system during a specific range of time, and human time is the best way to track those kinds of things.

Here's a patch

mvc

they

English

Montréal, CA

commented 17 June 2008 at 02:44

http://drupal.org/node/271398

There are many good reasons to use Unix timestamps, including support across a wide number of platforms. There's no reason they can't be used to express dates before 1970, except for how the test in node.module was written.

openflows.com