Issue with custom date formats

That makes sense, and I know how to fix it. It will probably be Monday the 5th before a fix is posted.

When you update the post, the CS date/time field parses the unix timestamp into a human-readable format according to your chosen date format–in your case, custom.

When you save your update, CS takes the date/time field and tries to parse it into a unix timestamp again for storage. The PHP DateTime class is not able to recognize / parse your custom format, so it chokes and stores 1st Jan, 2000.

I will:
1. Add error checking to notify the user if DateTime is unable to parse a format, instead of just silently failing.
2. Add hidden field to the CS form to hang on to the CS date time in a known, parseable format at all times.
3. Incidentally, you’ve made me realize CS saves the date time information every time you update the post–even if you didn’t change the CS date time. I’ll be fixing that, as well (just a performance issue for larger sites, but still…)

Thanks for reporting this–I’ll work on it for Monday.

Take care,
Paul

Well, what I meant by time stamp is Unix time, which is just an integer. This is how we’re storing your expiration time, in UTC. Then to display it for you we take into consideration your WordPress time zone and date / time formats to make it local and pretty.
http://en.m.wikipedia.org/wiki/Unix_time

In older versions of content scheduler, your expiration time was stored as a string, in format YYYY-MM-DD HH:MM:SS. What’s more, it was stored with your WordPress time zone already accounted for. This ended up creating a number of problems, as the expiration date became a moving target of sorts in some situations.

Anyway, your question is much appreciated and will see a fix in the next day or so.

Howdy,
Could you please let me know what your custom date / time formats are set to?
I think we’re good to go, but I want to test a couple more things before deploying version 2.0.6.
Thanks,
Paul