Page MenuHomePhabricator

Time-Variables like CURRENTTIME and CURRENTDAY should use time zones
Closed, ResolvedPublic

Description

The special variables CURRENTTIME, CURRENTDAY, etc seem to report the time as
UTC (resp. GMT). This leads to a lot of confusion, for example (in the german
WP) the votes for deletion end up on "yestardays" page until 2am (because CEST
is UTC +02:00). I wonder how this is done in the en:WP - is there a workaround?

It would be extremely useful if one could specify a time zone or offset in a
setup-file, so that those variables return the local time. Alternatively, it
would be good (but probably more complexe) to have the variables behave as
funtions, i.e. {{CURRENTTIME(CEST)}} would return the time as CEST. Dealing with
daylight saving time is anotehr issue - maybe Olson-DB names should be used
instead of time zones. But there is no support for that in PHP. (or is there?)


Version: unspecified
Severity: enhancement

Details

Reference
bz366

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 7:07 PM
bzimport set Reference to bz366.
bzimport added a subscriber: Unknown Object (MLST).

I second that we desperately need localised datetime variables. I believe they should bear a different name (maybe
LOCALTIME, LOCALDAY, etc.) since UTC ones may be useful to have an universaly agreeing timestamp if anyone needs one.

But this would be very good to get fixed either way. For me it doesn't seem to be complex to achieve, I'd guess at
most 3-5 lines of code would do it.

koneko wrote:

I'm against that , because many wiki have contributors from several timezones...

examples :
en: has users from ''Great Britain (GMT+0)'' as well as in ''USA (GMT-5 to
-9)'', Australia, New Zealand, Ireland...
fr: has users from ''Belgium, France (GTM+1) -adding the "Département
d'outre-mer" that have various GMT- , ''Switzerland (GMT+2)'', ''Quebec (GMT-5)''...
es: has users from ''Spain (GMT+1)'' as well as in most central and south
america, Philippines, Equatorial Guinea...

re #2: have you actually read #1? :-)

still, majority of national wikis would use LOCALtime in MOST places I believe.
en may be exception.
but there is the user settable "user local time" you remember, what about
USERLOCALTIME? As I told, it would be useful to have CURRENTTIME (utc) and
LOCALTIME (userlocal) together. Having only utc is bad (apart from enwiki). IMO..

I wonder whether I should provide a patch for this very complex problem. :-P
[even if I don't know php I could probably come up with one, as it is very
possibly an oneliner]
Please?

jediarchives11 wrote:

I also think that the last edit time should be displayed somewhere on the article page. I
think that it would be helpful.

Pleasing the majority is ignoring the minority. For Wikimedia projects UTC
should be used, as they are split by languages, not by countries. Other projects
can use other time zones, and magic words should work accordingly already.

jediarchives11 wrote:

So you are saying that we should ignore the majority and please the minority?
Both your local time and UTC should be used. For example, the comment above was
written at 22:38 UTC. What time was that for me? Was that written two hours ago,
7 hours ago? I have no idea. So it would be nice if times like those could be
put in local time, while vote closing times, for example, would be placed in UTC
and local time.

Also, I don't think that this issue is resolved yet.

  • Bug 4068 has been marked as a duplicate of this bug. ***

de.wikipedia, for example, is somehow set up to show everything in CE(S)T. The
only thing in the whole software that does not behave like that is the
CURRENTDAY etc. variables. This seems to me not a policy thing that has anything
to do with minorities and majorities, but a simple bug. Please fix, or at least
introduce some new variables for the time zones (or a possibility to add/deduct
a specified number of hours to the variable).

MediaWiki uses $wgLocaltimezone (for signatures) and $wgLocalTZoffset (default
for all other dates) to calculate the offset for date/time display. The values
of CURRENTTIME and CURRENTDAY should be consistent with the times zones defined
by those settings. Also, it may be a good idea to merge them, having two
settings for the same thing, but requiering a different syntax, seems silly.

  • Bug 4499 has been marked as a duplicate of this bug ***

uncle_ed_poor wrote:

Could we please get {{CURRENTHOUR}} and {{CURRENTMINUTE}} like the French
Wikipedia has? This would make time zone calculations easier in templates.

en.ABCD wrote:

(In reply to comment #11)

Could we please get {{CURRENTHOUR}} and {{CURRENTMINUTE}} like the French
Wikipedia has? This would make time zone calculations easier in templates.

It appears that those two templates are just workarounds - take a look at
http://fr.wikipedia.org/wiki/Template:CURRENTHOUR?action=edit and
http://fr.wikipedia.org/wiki/Template:CURRENTMINUTE?action=edit

koneko wrote:

Well, that was sure quite not brilliant of the creator to volontary use a
system-varaible-like name... (but it may be intended for an easier replacement
by a real system variable)

  • Bug 5727 has been marked as a duplicate of this bug. ***

rotemliss wrote:

Added local magic words in r16200.