Support » Plugin: Content Scheduler » Issue with custom date formats

  • This plugin seems to have an issue with custom date formats. My custom date format shows the day, date, year and time.

    When I create a new post and use Content Scheduler using the date picker I have no issues at all. However, once the post is published, under the date/time column in Content Scheduler, the input box shows the date and time according to my custom date format. Thus, when I update the post, Content Scheduler probably doesn’t recognise my custom date format and thus resets it to 1st January, 2000.

    Could there be a fix for this? Thanks!

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author Paul Kaiser


    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,

    Thanks so much for the quick response! Hmm, it is not possible for the timestamp to remain unparsed? I think that would be a much easier fix 🙂

    Plugin Author Paul Kaiser


    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.

    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.

    Ah, I see.

    Thanks a lot! 🙂

    Plugin Author Paul Kaiser


    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.

    Hi, Mine is set to l, jS F, Y

    Thank you.


    Any update on this issue?

    Thanks! 🙂

    Hi Paul, content scheduler does not seem to be working at all now. Some posts are expiring but most are not and the ones that do are not being moved into the Archives like they should be. Any update on the latest fix?


    Yes, a fix would be super nice … have a few websites that don’t work properly and need this fix. Thanks!

    Hi, any news about a new version? Hope it comes out soon!

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Issue with custom date formats’ is closed to new replies.