A scheduled time needs a time zone to be clear. Nine in the morning means different moments to people in different places. A publishing dashboard may also display a device-local time that differs from another team member's view.
Record one unambiguous plan
Write the intended date, time and named time zone in the release note. If the team works across regions, add the equivalent time each person needs. Check a reliable calendar or time-zone tool for the actual date rather than assuming that the offset is always the same.
Pay attention around seasonal clock changes. The relationship between two regions can change on different dates. A repeated weekly release should be reviewed when its named local time matters to the audience.
Enter the schedule in the hosting tool and inspect the saved value. Do not stop at the form submission message. Reopen the episode and compare the displayed schedule with the release note.
Keep scheduling separate from availability checks
A saved schedule does not prove that the audio, artwork and metadata are ready. Complete the normal delivery checks before relying on the scheduled release.
After publication, confirm that the intended item is public through the feed and normal listening path. Different services may update their copies at different times, so distinguish the host's publication from a directory's later refresh.
If the release time changes, update the single shared note and tell the people involved. Avoid leaving two competing schedule messages in chat. A small explicit record is easier to follow than several screenshots whose displayed time zones nobody can identify later.