anon.hui wrote:

To be less confuse in its meaning, I now change from CURRENTUSERTIMESTAMP to USERCURRENTTIME.
(Also change TIMESTAME to just TIME for more compact)

Add USER{CURRENT,LOCAL}TIME variable

• {{USER...TIME}}: format the time according to current user's date format

preference

Example

• {{USERCURRENTTIME}} --> 16:25, 27 May 2008 (UTC)
• {{USERLOCALTIME}} --> 01:25, 28 May 2008 (XXX)
• {{USERLOCALTIME:20080527160000}} --> 01:00, 28 May 2008 (XXX)

Apply this to default signature expansion

• ~~~~ --> User123 (talk) {{USERLOCALTIME:20080527160000}}

Note

• notice that {{USERLOCALTIME}} == {{USERLOCALTIME: {{CURRENTTIMESTAMP}} }}

anon.hui wrote:

For more flexibility, I now remove variable {{USERCURRENTTIME}},
and, instead, add variable {{USERTIME}} as a complement to {{USERLOCALTIME}}.

USERTIME/USERLOCALTIME variable

• {{USERTIME: ''UTC time in ISO-8601 format''}}: format the time according to current user's date format preference, in UTC timezone
• {{USERLOCALTIME: ''UTC time in ISO-8601 format''}}: format the time according to current user's date format preference, in local timezone (as specified in user's preference)

Example

• {{USERTIME: {{CURRENTTIMESTAMP}} }} --> 16:25, 27 May 2008 (UTC)
• {{USERTIME: 20080527160000 }} --> 16:00, 27 May 2008 (UTC)
• {{USERTIME}} --> {{USERTIME: {{CURRENTTIMESTAMP}} }}

• {{USERLOCALTIME: {{CURRENTTIMESTAMP}} }} --> 01:25, 28 May 2008 (XXX)
• {{USERLOCALTIME: 20080527160000 }} --> 01:00, 28 May 2008 (XXX)
• {{USERLOCALTIME}} --> {{USERLOCALTIME: {{CURRENTTIMESTAMP}} }}

herd wrote:

This would break caching, or be broken by caching. For example: a server-wide timestamp is static until the page is purged, but a username showing in a page would be cached and be wrong for the next viewer. However, there is the possiblity of allowing user-specific magic words that are subst'able only.

Related:

• https://bugzilla.wikimedia.org/show_bug.cgi?id=4196
• https://bugzilla.wikimedia.org/show_bug.cgi?id=10336

anon.hui wrote:

All above are summarized in, http://www.mediawiki.org/wiki/Bugzilla/14286

anon.hui wrote:

http://www.mediawiki.org/wiki/Bugzilla/14286#Problem <-- AJAX is one possible solution to solve caching

anon.hui wrote:

(In reply to comment #3)

This would break caching, or be broken by caching. For example: a server-wide
timestamp is static until the page is purged, but a username showing in a page
would be cached and be wrong for the next viewer. However, there is the
possiblity of allowing user-specific magic words that are subst'able only.

Related:

• https://bugzilla.wikimedia.org/show_bug.cgi?id=4196
• https://bugzilla.wikimedia.org/show_bug.cgi?id=10336

Is it possible to do post cache processing?

1. Server read content from cache
2. Server modify the date/time (in read content) according to user preferences
3. Server Send the modified result to client

anon.hui wrote:

It may be complicate to implement at this time.
Waiting for mediawiki to support AJAX, may made this easier to implement.

To be reconsidered later.

anon.hui wrote:

(In reply to comment #3)

This would break caching, or be broken by caching. For example: a server-wide
timestamp is static until the page is purged, but a username showing in a page
would be cached and be wrong for the next viewer. However, there is the
possiblity of allowing user-specific magic words that are subst'able only.

Related:

• https://bugzilla.wikimedia.org/show_bug.cgi?id=4196
• https://bugzilla.wikimedia.org/show_bug.cgi?id=10336

The already implemented {{int:...}} also kill content caching?

(In reply to comment #8)

The already implemented {{int:...}} also kill content caching?

No, but it can cause link table inconsistency, so it can't be used as an argument.

(In reply to comment #6)

Is it possible to do post cache processing?

1. Server read content from cache
2. Server modify the date/time (in read content) according to user preferences
3. Server Send the modified result to client

No, it's not possible with how Mediawiki works.

(In reply to comment #7)

It may be complicate to implement at this time.
Waiting for mediawiki to support AJAX, may made this easier to implement.

Mediawiki already uses AJAX, we've been bundling Sajax forever now, and we've been moving to jQuery in recent months. That being said, a Javascript-based solution wouldn't be ideal either. You could probably write it as a userscript/Gadget though.

To be reconsidered later.

Marking WONTFIX per bug 4196 and comment #3