Publish on date reverts to 1970 because scheduler interprets the text to be the number of seconds.

just changed the title to something a little more useful

Got a bit further at tracking this bug down. It seems to be to do with the way the supplied date/time is parsed.

If you put "18 September 2008", the value changes to 1970-01-01 01:00:18. My time zone is GMT+1, so it's 18 seconds after zero time (1970-01-01 01:00:00 in my zone). It's parsed the "18", and made that the number of seconds after zero that it stores.

If I put "2009-01-01 06:45:00" as my value, it turns into 1970-01-01 01:33:29, as described above. Now I know that it's storing the number of seconds after 1am on 1st Jan 1970, I convert 33 minutes and 29 seconds into seconds. ... 2009 seconds! So it's parsed the 2009 bit.

If I put 20090101, it turns it into 20 million, 90 thousand and 101 second after 1am on 1st Jan 1970.

What I think it's doing is not parsing at all. I don't think my input is going into strtotime. I think it's doing a best guess at casting my input into a 32-bit integer, and then storing that value.

In case it helps anyone reproduce this: I'm using PHP5.2.5

Can you post the date format from /admin/settings/scheduler, please.

I'm using the default. Y-m-d H:i:s

Doing a bit of debugging, it looks to me like the case 'presave': section never gets entered.

Under the case statement, I've put $node->publish_on = 1229904000; (should be near abouts 1st Jan 2009), then commented out everything else until the break; statement. It doesn't change the behaviour I've described. (It should give every node a scheduled publish date whether I want one or not).

I always click "Preview" not "Save", because all that "Save" does is make the node publish immediately, but I can't see what "publish on" date made it do that.

Does anybody else get the same problem? My setup seems so typical that I'm really surprised that the problem isn't more widely reported.

OK. Done some further tests. It seems this is actually two issues. One is a bug. One may be a "by design" feature, or may be a bug - only the module author can tell us that.

1. The bug first: Clicking "Preview" on the Create Node page breaks the values in the publish on field. Specifically
   • When creating a brand new node that hasn't been saved to the database, the contents of the "(un)publish on" textbox are changed, parsing what was entered as if it were a number. The contents of the textbox after clicking preview are the date/time you get by adding this number of seconds on to time zero.
   • When editing the "publish on" date/time for a node that already exists, any changes made to the "publish on" date/time are ignored when preview is clicked. E.g., if a node was to be published on the 1st Dec 2008, and the field is changed to 2nd Dec 2008, clicking preview will revert the value to 1st Dec again.

Probably related to this, I think the validate hook is not being invoked. If I put misformatted dates in the text boxes, or if I enter an unpublish date that is before a publish date, I don't get any error triggered.

2. Now for the bug that might be a feature: The date / time string entered has to be formatted exactly in the format given. I'm using the default: yyyy-MM-dd hh:mm:ss. If I just enter 2008-12-01, and click "save" (because "preview" doesn't work as expected), the node is published immediately, and it seems my string is treated as a blank (or possibly as 2008 seconds after 1970-01-01). If the module wants publish-on dates down to the hours, minutes and seconds granularity, then that is what I must enter.

   I can see that this could be by design. I wonder if it's a bug instead, because I used to use 5.x-1.8, and then I was allowed to enter a date with no time, or a date and time that doesn't specify the number of seconds, and the module would be lenient with me.

Marked back from "critical" to "normal", because (now I understand the module's behaviour) I can work around it.

James,

I will be working on all open issues this week. Things have been quite busy...

Eric

With #8 I can reproduce the behaviour. Thanks, James. I still consider it critical. Stay tuned.

I know now why the date vanishes and the validation is not running, but if I fix it, it breaks something else. :-(
I need to dig a little deeper into nodeapi...

http://drupal.org/cvs?commit=150522

Ok, it is still not perfect. It keeps the values if the node is brand new. If the node was already saved and edited again, it still looses the values.

OK, I got it.
James could you please verify it. I checked it in (http://drupal.org/cvs?commit=150598) and also attached a patch in case you cannot use cvs.

Sorry I can't access this.

I tried the cvs link first, to try and download the complete .module file. All I got was an HTML rendering of the diff from the previous version. I guess that's because I haven't got a CVS account.

I tried to browse through CVS contributions to download the latest version, but when I get to the Scheduler module (http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/scheduler) there's nothing there. I'm afraid I'm showing my ignorance of how to navigate the Drupal CVS - I must be looking in the wrong place.

So, final attempt, I downloaded the .patch file, and applied it to the 6.x-1.2 .module file. But "2 out of 2 hunks FAILED" was the result - so I guess the .patch file presupposes some other changes such that the 6.x-1.2 .module file is too different for patch.exe to handle.

Any chance you could post the current version of scheduler.module here (or correct my ignorance on how to browse through cvs.drupal.org?

Here's the complete current state. I don't want to make a release until all the changes are verified...

Works fine for me.

Thanks Eric

Fixed in 6.x-1.3

Automatically closed -- issue fixed for two weeks with no activity.