Skip to content
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

Closed
Amalthea opened this issue Jun 2, 2011 · 6 comments · Fixed by #1132
Closed

Avoid using the client clock for anything #6

Amalthea opened this issue Jun 2, 2011 · 6 comments · Fixed by #1132
Labels

Comments

@Amalthea
Copy link
Collaborator

Amalthea commented Jun 2, 2011

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.

@hartman
Copy link
Collaborator

hartman commented Jun 5, 2011

When you request a page for later editing from the api, you already get the starttimestamp in UTC. Can't that be reused ?

@Amalthea
Copy link
Collaborator Author

Amalthea commented Jun 5, 2011

Of course, very good! I kept thinking it needed another request to expand #time or something.

@DannyS712
Copy link
Contributor

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

@siddharthvp
Copy link
Member

@siddharthvp
Copy link
Member

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.

siddharthvp added a commit to siddharthvp/twinkle that referenced this issue Oct 29, 2019
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.
@siddharthvp
Copy link
Member

When you request a page for later editing from the api, you already get the starttimestamp in UTC. Can't that be reused ?

Indeed. Opened a PR for reusing this wherever possible.

siddharthvp added a commit to siddharthvp/twinkle that referenced this issue Oct 29, 2019
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.
siddharthvp added a commit to siddharthvp/twinkle that referenced this issue Nov 8, 2019
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()`.
siddharthvp added a commit to siddharthvp/twinkle that referenced this issue Jan 7, 2020
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()`.
@Amorymeltzer Amorymeltzer linked a pull request Oct 6, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants