Posting/Editing: posts created and edited in the app then edited on the web are published with the wrong date

[designsimply]

Expected behavior

I expect the current date and time to be used when I click the Publish button on a draft regardless of where it was edited.

Actual behavior

If a draft created in the app is edited using the app and then edited using the Calypso editor, the final publish date will be the creation date from the app.

Steps to reproduce the behavior

1. In the app, create a new post.
2. Add a title.
3. Add a line noting the current time.
4. Save the post as a draft.
5. Wait 2+ minutes.
6. In the app, close and re-open the same post.
7. Add a line noting the current time.
8. Save the post as a draft again.
9. Wait 2+ minutes again.
10. On the web, re-open the same post using the Calypso editor.
11. Observe what it says next to “Publish” under Settings (gear icon at top right) > Post > Status & visibility > Publish.
12. You can either publish the post from the app or the web now and the result will be the same.

Results: if a revision is saved by the iOS app and the post is edited using the Calypso editor after that, the post publish date will be set to the date and time it was originally created in the app and not the date and time the post is actually published.

Notes: you can hover over the publish date in the Posts list on the web to see the exact date of publish (screenshot).

Tested on iPhone 11, iOS 15.0 beta 6, WPiOS 18.0.2 (TestFlight beta).

^{/hat tip @elibud for the bug report and @startuptester for help confirming the steps to reproduce.}

^{/cc @aerych because I believe you have worked on this sort of thing in the past and you may have tips about how to solve the problem.}

[aerych]

/cc @aerych because I believe you have worked on this sort of thing in the past

Maybe something related? It sounds familiar, but I don't remember the web component.

and you may have tips about how to solve the problem.

I'd guess it might be related to how (if?) the apps set/update the value of date_created. It would be interesting to see if calypso is or is not setting the date_created when saving drafts and compare that behavior with the apps.
FWIW, we could try always updating date_created for drafts in the apps but there might be a catch. When testing on the web it looks like if a post was published and then switched back to a draft the original published date is preserved.

[momo-ozawa]

I didn't have time to fix this issue during my Groundskeeping rotation, but below are my investigation notes.

If a draft post is edited in the app, the publish date is set to the previous revision date -- you don't need to edit the post in Calypso to repro this issue.

I'd guess it might be related to how (if?) the apps set/update the value of date_created.

It is.

A draft post will "publish immediately" only when date_created_gmt and the dateModified match:

WordPress-iOS/WordPress/Classes/Models/AbstractPost.h

Lines 23 to 28 in a08cc72

	/**
	The dateModified field is used in tandem with date_created_gmt to determine if
	a draft post should be published immediately. A draft post will "publish immediately"
	when the date_created_gmt and the modified date match.
	*/
	@property (nonatomic, strong, nullable) NSDate * dateModified;

WordPress-iOS/WordPress/Classes/Models/AbstractPost.m

Lines 426 to 429 in a08cc72

	- (BOOL)shouldPublishImmediately
	{
	return [self originalIsDraft] && [self dateCreatedIsNilOrEqualToDateModified];
	}

WordPress-iOS/WordPress/Classes/Models/AbstractPost.m

Lines 247 to 250 in a08cc72

	- (BOOL)dateCreatedIsNilOrEqualToDateModified
	{
	return self.date_created_gmt == nil || [self.date_created_gmt isEqualToDate:self.dateModified];
	}

It would be interesting to see if calypso is or is not setting the date_created when saving drafts and compare that behavior with the apps.

It looks like Calypso updates date_created when saving drafts. On the app, we do not update date_created_gmt when saving drafts, which is why the post isn't published immediately if there's a revision created in the app.

When testing on the web it looks like if a post was published and then switched back to a draft the original published date is preserved.

Currently on the app if you revert a published post to a draft post (Post Settings > Status > Draft), the original publish date is preserved. However we'll need to make sure that updating date_created_gmt doesn't cause regressions for this flow

WordPress-iOS/WordPress/Classes/ViewRelated/Post/Scheduling/PublishSettingsViewController.swift

Lines 43 to 44 in c27ea7c

	if let dateCreated = post.dateCreated, post.shouldPublishImmediately() == false {
	state = post.hasFuturePublishDate() ? .scheduled(dateCreated) : .published(dateCreated)

[alpavanoglu]

I've tried quite a bit of things here. I made it work on iOS but I suspect there's a problem on Calypso too.
After talking with an engineer from Calypso Team, I was told that date_created_gmt shouldn't be updated in draft status. So only a published post should have creation date. Following this I added the following code to class PostService in - (RemotePost *)remotePostWithPost:(AbstractPost *)post function:

    if (![post originalIsDraft]) {
        remotePost.date = post.date_created_gmt;
    }

This way we would only update the date when a post is not draft. And when we pass nil for the remotePost.date, I suspect backend just returns us the dateModified in that field as well so the comparison mentioned by @momo-ozawa ("The dateModified field is used in tandem with date_created_gmt...") results in "publish immediately". This resolves the issue on iOS.

BUT after doing an update on the draft from iOS, if we go ahead and do an update from Calypso, the remotePost.date we receive from backend becomes the last date that an update through iOS was made. Here I suspect there's an issue on Calypso. Because until that point we have never sent backend a date and only dateModified. I don't know how Calypso falls back on this value but there is surely a difference between how two platforms use/update these values. Without an API contract, it is hard to say what we must do.

TIP for testing this:
Instead of waiting minutes between updates, one can note down minute:second and compare against that so that it is more efficient/fast.

[kean]

The "Publish Date" fields was removed in 24.9 and the app never sends the dateCreated field updates with the only exception right before publishing if you select a custom publish date.