The discussion revolves around enhancing the Topic Timer feature in Discourse. outofthebox suggests three improvements: a popup for selecting custom times, displaying the selected time in notifications, and including the time zone (e.g., “9am Eastern Standard Time”). codinghorror questions the need for time zones, arguing the timer is local to the user’s perspective. outofthebox clarifies that while the system works correctly, visibility of the time zone would add confidence, especially for global teams. cogdog supports this, noting that time zone clarity is essential for international organizations to avoid publishing announcements at the wrong time, and suggests indicating the local time in the interface to aid less experienced users.
For the first time I did it, the time itself doesn’t appear in the notification, so I was hesitant/unsure that it was set properly. Then, I wondered what time zone the system would use for the topic timer. But, it all worked out.
In general, I think the time zone feature would be magic for doing announcements/posts in our global community. If I want to get something out for our team in Oxford at the start of their workday, knowing that I have it configured for 8am BST adds clarity and confidence to the workflow.
Late to the question, but was wondering the same thing while testing out the topic timers for an important announcement of awards being given out by our organization and I do not want to publish it at the wrong time.
It might help the less discourse savvy (like me) if the interface indicated the time was local. But to be sure I created a test at 10am local, set a custom date (today) and time (noon), and the interface did indicate that it would be published 2 hours from now.
A time zone reference (like the Insert date/time in the editor) is handy for us as we are an international organization.