Last modified: 2011-03-13 18:06:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16286, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14286 - local timezone conversion / {{USERTIME}},{{USERLOCALTIME}} for time formatting / signature time expansion
local timezone conversion / {{USERTIME}},{{USERLOCALTIME}} for time formattin...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.13.x
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.mediawiki.org/wiki/Bugzill...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-27 08:20 UTC by Anon Sricharoenchai
Modified: 2011-03-13 18:06 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Anon Sricharoenchai 2008-05-27 08:20:09 UTC
== 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
Comment 1 Anon Sricharoenchai 2008-05-28 04:21:57 UTC
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}} }}
Comment 2 Anon Sricharoenchai 2008-05-28 05:16:17 UTC
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}} }}
Comment 3 Splarka 2008-05-28 05:29:03 UTC
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
Comment 4 Anon Sricharoenchai 2008-05-28 05:49:01 UTC
All above are summarized in, http://www.mediawiki.org/wiki/Bugzilla/14286
Comment 5 Anon Sricharoenchai 2008-05-28 05:56:59 UTC
http://www.mediawiki.org/wiki/Bugzilla/14286#Problem <-- AJAX is one possible solution to solve caching
Comment 6 Anon Sricharoenchai 2008-05-28 06:55:40 UTC
(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
Comment 7 Anon Sricharoenchai 2008-05-29 12:17:58 UTC
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.
Comment 8 Anon Sricharoenchai 2009-03-02 06:03:54 UTC
(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?
Comment 9 Niklas Laxström 2009-03-02 07:42:19 UTC
(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.

Comment 10 Chad H. 2009-10-29 23:39:22 UTC
(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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links