You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
User/channel time zone/format preferences shouldn't live in a plugin. Those preferences are used by core API features, most notably the tools.time subpackage, and many other first- & third-party plugins rely on them to correctly format their output.
The functions to set/get/clear time zone & time format preferences for both users and channels probably should live in coretasks.
As I wrote in my do-something-about-this-someday text note: "[These clock features that couple to core API functions] are almost as bad as when disabling [the url plugin] broke the @url decorator."
I think I'd like to split up coretasks and compartmentalize protocol handling from always-available core commands like .blocks and the time-preference stuff I'm proposing to adopt here, but that's a separate discussion.
The text was updated successfully, but these errors were encountered:
User/channel time zone/format preferences shouldn't live in a plugin. Those preferences are used by core API features, most notably the
tools.time
subpackage, and many other first- & third-party plugins rely on them to correctly format their output.The functions to set/get/clear time zone & time format preferences for both users and channels probably should live in
coretasks
.As I wrote in my do-something-about-this-someday text note: "[These
clock
features that couple to core API functions] are almost as bad as when disabling [theurl
plugin] broke the@url
decorator."I think I'd like to split up
coretasks
and compartmentalize protocol handling from always-available core commands like.blocks
and the time-preference stuff I'm proposing to adopt here, but that's a separate discussion.The text was updated successfully, but these errors were encountered: