fix(gdoc): unstable publication time triggers duplicate Mailchimp newsletter

[mlbrgl]

Interacting with the gdocs date picker changes the underlying time, in addition to the visible date. This change makes it all the way to the atom feed, which is then interpreted by Mailchimp RSS-to-Email feature as a new article to be sent.

This happens in two instances.

1. Interacting with the date picker calendar, e.g. going from Oct 11, to Oct 10 and back to Oct 11:

publishedAt Wed Oct 11 2023 00:59:53 GMT+0100 (British Summer Time)
publishedAt Tue Oct 10 2023 01:59:53 GMT+0100 (British Summer Time)
publishedAt Wed Oct 11 2023 02:59:53 GMT+0100 (British Summer Time)

Notice how that third time is now 02:59:53 vs 00:59:53 originally.

2. Pressing the "Today" button sets the time to the current time

This PR fixes 1 and removes the "Today" button so that the time remains unchanged from the first publishing event.

see slack

[mlbrgl]

Current dependencies on/for this PR:

• master
  • PR fix(gdoc): unstable publication time triggers duplicate Mailchimp newsletter #2698 👈

This comment was auto-generated by Graphite.

[ikesau]

Nice! I noticed this too when investigating the scheduled post thing. Thanks for fixing it.

I wonder if it would be better to just change the column to DATE though. updatedAt is still useful to have a timestamp, but it's not like the time an author pressed the publish button is used anywhere / relevant for in citations.

import { MigrationInterface, QueryRunner } from "typeorm"

export class ConvertPostGdocsDatetimetoDate1696422487206
    implements MigrationInterface
{
    public async up(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.query(
            `ALTER TABLE posts_gdocs MODIFY publishedAt DATE`
        )
    }

    public async down(queryRunner: QueryRunner): Promise<void> {
        await queryRunner.query(
            // All the times will be 00:00:00
            `ALTER TABLE posts_gdocs MODIFY publishedAt DATETIME`
        )
    }
}

[mlbrgl]

@ikesau good point, you're right, we don't really have a use for the published time on the frontend.

Having this information around has been useful for debugging, though, so I'd be tempted to keep it around if all else is equal.

[ikesau]

Okay 🙂

[mlbrgl]

Tangentially related: I'm adding a discussion point to our next P&D meeting regarding dateline (in frontmatter) vs publication date in the admin.