Improve Inline Timestamp Authoring UX #929
temportalflux
started this conversation in
Feature Suggestions
Replies: 1 comment 1 reply
-
I've made an external tool that does almost exactly what you've asked for. I'll try to share it tomorrow. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I love that the inline timestamp feature exists both on Revolt and Discord, but authoring the inline timestamps (e.g.
<t:1543392060>
) has a lot of friction when it comes to getting people to use it (at least in the discord servers I'm a part of). It often requires using a generator such as sesh.fyi, epoch converter, or discord timestamps. Each of those has their own UX and even getting people to use a timestamp generator to convert a human-readable date into a unix epoch has tended to be a larger ask then many folks are willing to do to refer to a date/time. Having the timestamps in a message is incredibly useful though, especially for teams which span multiple timezones. I've love to see Revolt iterate on this feature and lower the barrier of entry to authoring inline timestamps which display as local-time on the reader's client.I have some preconceptions/ideas as to what this UX could look like. Assuming the opening and closing characters are kept the same (
<...>
or<t:...>
), a first iteration could prove out the concept by allowing any ISO-8601 matching string. e.g.<2025-01-01T15:30-05:00>
aka "January 1, 2025 at 3:30pm UTC-5 (US Eastern Standard)". When rendering the message, the local client could pattern/regex-match the contents of the timestamp to see if it matches either the unix formatt:...
or the ISO formatYYYY-MM-DDTHH:MM±hh:mm
(the latter being converted to a unix timestamp to be rendered as such). This would still have a high UX overhead, since it relies on users providing the timezone offset (and the full ISO format). Aside; I've not thought about how to integrate the "style" tag of inline-timestamps into this yet, but I imagine it could still be a character at the end of the ISO format.If that proof of concept works, I could imagine additional patterns being added as syntactic-sugar. Cases like
2pm EST
could be reinterpreted on the client via concatenating the message's timestamp date (e.g. August 23, 2024) to make<2024-08-23T14:00-05:00>
, while03/10 12pm PDT
could be filled with the next year the authored month occurs next after the message's sent date (e.g. May 2025) to make<2025-03-10T12:00-07:00>
. The most drastic filling shorthand would be<5pm>
, which would require the message's sent timestamp date AND the timezone the message was sent from (e.g. June 12, 2025 CEDT, UTC+2), so that the resulting ISO format would be equivalent to<2025-06-12T17:00+02:00>
.Regardless of my theories as to what it could be implemented as, I'd love to see improvements to the discord-inline-timestamp message syntax so my peers and I are able to write a local time and have the reader always see their local time.
Beta Was this translation helpful? Give feedback.
All reactions