local timezone conversion / {{USERTIME}},{{USERLOCALTIME}} for time formatting / signature time expansion
Closed, DeclinedPublic

Description

Author: anon.hui

Description:

Add localtime conversion capability to LOCAL{TIMESTAMP,YEAR,...} variable

  • {{LOCALTIMESTAMP}}: current local time stamp in iso-8601 format
  • {{LOCALTIMESTAMP:''UTC time in ISO-8601 format''}}: convert the specified UTC time to local time stamp

Example

If user's timezone preference is +0900,

  • {{LOCALTIMESTAMP:20080527160000}} --> 20080528010000
  • {{LOCALYEAR:20080527160000}} --> 2008
  • {{LOCALMONTH:20080527160000}} --> 05
  • {{LOCALDAY:20080527160000}} --> 28

Add {CURRENT,LOCAL}USERTIMESTAMP variable

  • {{...USERTIMESTAMP}}: format the time according to current user's date format preference

Example

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

Apply this to default signature expansion

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

This will be useful that,

  • the readers will see the signature's timestamp in their prefer timezone and format
  • the signature's timezone and format will be consistent with what shown in revision history

Version: 1.13.x
Severity: enhancement
URL: http://www.mediawiki.org/wiki/Bugzilla/14286

bzimport added a project: MediaWiki-Parser.Via ConduitNov 21 2014, 10:14 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz14286.
bzimport created this task.Via LegacyMay 27 2008, 8:20 AM
bzimport added a comment.Via ConduitMay 28 2008, 4:21 AM

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}} }}
bzimport added a comment.Via ConduitMay 28 2008, 5:16 AM

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}} }}
bzimport added a comment.Via ConduitMay 28 2008, 5:29 AM

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:

bzimport added a comment.Via ConduitMay 28 2008, 5:49 AM

anon.hui wrote:

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

bzimport added a comment.Via ConduitMay 28 2008, 5:56 AM

anon.hui wrote:

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

bzimport added a comment.Via ConduitMay 28 2008, 6:55 AM

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:

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
bzimport added a comment.Via ConduitMay 29 2008, 12:17 PM

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.

bzimport added a comment.Via ConduitMar 2 2009, 6:03 AM

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:

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

Nikerabbit added a comment.Via ConduitMar 2 2009, 7:42 AM

(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.

demon added a comment.Via ConduitOct 29 2009, 11:39 PM

(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

Add Comment