What is the difference between sys_pubdate and sys_contentstartdate?
These fields seem to do the same thing, is that correct?
OK met with Dr Rhythmyx yesterday, what a cool dude you are David, and got the answer.
sys_pubdate is populated by Rhythmyx when the content item actually gets published
sys_contentstartdate is the date the content is allowed to be published and can be set by the CMS user!
Hi
We, at NHM, use the sys_pubdate field differently… like the sys_contentstartdate, it is set by the user and publishes out as the official date for News stories and press releases. We have a default date for sys_contentstartdate which is the current date + time of when the item was created, but can be changed to facilitate an aging transition to move the item to public. The sys_pubdate is manually set to display the actual date the item was ‘released’ i.e. published live.
This decision was made to allow news stories + press releases to be created in advance and put to the Pending state to await the sys_contentstartdate the user specified.
Cara
Cara,
The sys_pubdate will be overwritten by the publisher when the item is actually published. This includes cases where the item didn’t really change, but was “touched” because some other item changed.
In your scenario, I don’t see why you just don’t use the “Content Start Date” as the release date of the item.
Dave
Dave,
You mentioned below that the sys_pubdate is overwritten by the publisher when the item is published…has this behavior changed in 6.7? I have noticed that in our content items that are published, the sys_pubdate is null. (It does not matter whether I add the fields to the content type or not…i assume that similar to the sys_contentlastmodifieddate that i do not need to explicitly add that field to the content type). Is there a configuration on the workflow (or publishing tab) that needs to happen in order to the get the publisher to fill in the sys_pubdate?
I do not know if it worked for us in 6.5.2 as I had not used that field before.
Jit
Jit,
It appears that this is broken in 6.7. I haven’t used it in a while, but I’m pretty sure that it worked in 6.5.2, so I’ll report a bug.
You can, of course, use the “last modified” date if you want to display when the item was last changed. I realize that this is not exactly the same thing, but they will usually be reasonably close.
Dave
Dave,
If this feature is broken, when can we generally expect some fix for it?
In our case, we cannot use content modified date, as our users will modify and publish items on different dates.
Ravi
At this point, I cannot predict when this will be fixed: we prioritize these fixes in response to customer demand, so if you need it fixed, the best thing to do is contact tech support and let them know.
You should understand, however that the “modify” date is the last time ANYTHING was changed, including workflow state and changes to items that are linked to this item. There are also some “system processes” that may change the modification date. All of these processes will cause a re-publish to occur the next time the publisher runs. So in normal operation, the modify date is never very far away from the publish date.
If you need to track the date when the user last edited the item, you should include a separate date field for that. If you just need to know when the item was last published, the system modify date is a pretty good approximation. It is possible, of course, to determine the exact publish date and time from the system log tables.
Dave
Dave,
Following your previous post, we had contacted Tech Support about the fact that sys_pubdate was not being updated in 6.7. We received a reply that it would be fixed in a future release. No ETA though.
Thanks,
Jit
We create translation items from default en-us items. The sys_contentstartdate displays the same date as the en-us parent item’s sys_contentstartdate. How to change that behavior so that the Start date displays the date when the translation items are actually created?
Pallavi