https://bugzilla.wikimedia.org/show_bug.cgi?id=32351

--- Comment #7 from Bawolff <bawolff...@gmail.com> 2011-11-18 14:14:38 UTC ---
(In reply to comment #6)
> > I don't really like #time: with no formatting string being user pref. It 
> > should probably have some symbol to specify that user time preference is
> > wanted.
> 
> #time does not interpret format string, but pass it to Language::sprintfDate. 
> I
> do not like an idea to parse format string in #time -- it is not trivial due 
> to
> backslashes, double quotes, di- and trigraphs. So for #time simplicity, format
> string should be passed to Language::sprintfDate. The latter can be modified
> asily to recognize one more special character. But, since it is just a place
> holder for user-specific format string, it should be parsed. Natural way to
> parse format string is pass it to Language::sprintfDate… This makes
> Language::sprintfDate a recursive function, so we should take special care
> about infinite recursion. Let us don't overcomplicate this stuff. Empty format
> string is good enough for denoting user-defined date/time format.


That's a good point. It doesn't entirely seem right to me to have the empty
string be the user pref, but I'll withdraw my objections on that point.

Although, one could also just combine #time and #dateformat to achieve the same
affect.

> > Having timel be user preference time is also something I'm not sure how i 
> > feel
> > about. If we want that it should perhaps be a different name then something
> > already used for server time.
> 
> Who (except sever admins) takes care of server time? Server can be located in
> any place in the world, in any timezone, it should not make difference for
> users.

Often times you want to display the same info to everyone (for example in user
signatures, the common argument is that if they were all user time, then when
people copied and pasted the time to someone else, people would get confused
what the actual time is, since different people would see different times.
Server time often represents where the majority of the user base is located.
For example Korean Wikimedia projects use the time zone Asia/Seoul as server's
local time zone.


> 
> > However, if we do make timel be user time, then we'd need to make sure user
> > time preferences are added to parser cache key, or it will be all mixed up
> 
> Which cache? Do you mean this case (a beginning of `time' function in
> `ParserFunctions_body.php'): 
> 
>     if ( isset( self::$mTimeCache[$format][$date][$language][$local] ) ) {
>         return self::$mTimeCache[$format][$date][$language][$local];
>     }
> 
> Err… I am not experienced Mw-PHP-Web hacker… Is this variable shared between
> different HTTP requests? If not, it seems everything is in place.
> 
> I am worrying about another cache. Can MW cache entire pages and return 
> already
> rendered page to different users? If so, either result of #timel will be
> reported incorrectly, or #timel can invalidate cache and load the server
> heavily. However, I am not sure, it is just a guessing.

Yes, I meant the cache that cache's the rendered html version of the page, and
displays it to other users (we refer to it as the parser cache). We do store
rendering options with the parser cache, which can allow the cache to vary by
user preference based on user options. (For example, we vary based on user's
preferred date format in the preferences). In order to make the #time's vary by
user timezone preference, the timezone would have to be added to the list of
things the parser cache varies by, which could potentially have some negative
performance impact, since it would fragment the cache (although if it was a
sufficient amount of an impact to care, is something I don't know).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to