Allow for "relative fixed" expiries in temporary commands
underscore11code opened this issue ยท 0 comments
Description
A not-uncommon request I see in support channels is the ability to use what I'm calling "relative fixed" expiries in the various temporary commands. These are expiries that have a fixed expiry time (i.e. midnight), but a relative date (i.e. "in X days", "next Sunday", "the X day of the following month"). As expiries are already stored as fixed timestamps, and we already calculate offsets in most cases (the 4d2h0m
syntax), this should be fairly simple and lightweight to implement if desired.
Proposed Behaviour
Extend the parser for temporary expiries to allow parsing a third format. I'm not entirely sure how best to define this format, but it would need to have 2 components, a fixed time and a relative date.
The fixed time part should be easy, just a HH:MM
, possibly with aliases for midnight and maybe noon. These times would have to be in the server's time zone, since we can't access the player's time zone to have the time be in their time zone.
The relative date part is where I'm unsure how best to define a format, but it should support the following date "descriptors" to be useful:
- "in X days" / "the following day"
- "in X weeks on [day of the week]" / "the following [DOTW]" i.e. "in 2 weeks on sunday" or "the following friday"
- "on day X of the month, Y months from now" / "on day X of the following month"
Extra Details
I acknowledge this is somewhat of a niche feature, and I wouldn't be surprised if folks think it's out of scope - I'm borderline on it too. The main use of this would be automated systems that have canned rewards or such, since for manual usage, admins could just use the unix timestamp of the desired expiry if need be.
Figured I'd open an issue anyways though, best case it gets added and people are happy, worst case it gets closed as out of scope and we have a more definitive answer than "that's not currently a feature" and can point to this issue when people ask about it.