-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid using the client clock for anything #6
Comments
When you request a page for later editing from the api, you already get the starttimestamp in UTC. Can't that be reused ? |
Of course, very good! I kept thinking it needed another request to expand #time or something. |
What about, at least of section headers and adding the time to a page, using substituted time parser functions? See https://en.wikipedia.org/wiki/Help:Magic_words#Other_variables_by_type |
In all the places where we need to add time to a page (CSD/PROD userspace logging and user talk page warning), we also need to check whether the section header of the current month is already there, so we must have the time beforehand. |
Largely addresses wikimedia-gadgets#6. Per wikimedia-gadgets#6 (comment), the server time is available to us whenever we are in a `.load()` callback, via the starttimestamp attribute in load API output which is stored in Morebits.wiki.page as ctx.loadTime, publicly exposed via `.getLoadTime()`. The only remaining usages of client clock is in: - an3 - not important to fix as it is only used for deciding what revisions to retrieve from which user can select reverts. - in determining daily log page name for RFD, CFD, FFD, TFD. The code that does is sitting outside of any load callback, because unlike in AfD, tagging of the page is ocurring after the discussion is posted. Maybe the order can be changed in a future Great XfD De-Duplication Project.
Indeed. Opened a PR for reusing this wherever possible. |
Largely addresses wikimedia-gadgets#6. Per wikimedia-gadgets#6 (comment), the server time is available to us whenever we are in a `.load()` callback, via the starttimestamp attribute in load API output which is stored in Morebits.wiki.page as ctx.loadTime, publicly exposed via `.getLoadTime()`. The only remaining usages of client clock is in: - an3 - not important to fix as it is only used for deciding what revisions to retrieve from which user can select reverts. - in determining daily log page name for RFD, CFD, FFD, TFD. The code that does is sitting outside of any load callback, because unlike in AfD, tagging of the page is ocurring after the discussion is posted. Maybe the order can be changed in a future Great XfD De-Duplication Project.
Largely addresses wikimedia-gadgets#6. Per wikimedia-gadgets#6 (comment), the server time is available to us whenever we are in a `.load()` callback, via the starttimestamp attribute in load API output which is stored in Morebits.wiki.page as ctx.loadTime, publicly exposed via `.getLoadTime()`.
Largely addresses wikimedia-gadgets#6. Per wikimedia-gadgets#6 (comment), the server time is available to us whenever we are in a `.load()` callback, via the starttimestamp attribute in load API output which is stored in Morebits.wiki.page as ctx.loadTime, publicly exposed via `.getLoadTime()`.
Twinkle uses the client clock for numerous tasks: section headers in user warnings and list pages for various XfD tasks come to mind.
Since client clocks are often a bit off (this comes up regularly), it would be beneficial to ask the server for the time, and use that one.
The text was updated successfully, but these errors were encountered: