Page MenuHomePhabricator

Add {{CURRENTHOUR}} and {{CURRENTMINUTE}} magic words
Closed, ResolvedPublic

Description

{{CURRENTTIME}} is the only time-related magic word that returns a string
instead of a number. Because of that, it is incompatible with parser functions.
Having {{CURRENTHOUR}} and {{CURRENTMINUTE}} would solve that, and make time
zone handling templates possible without having to resort to perversions like
http://en.wikipedia.org/w/index.php?title=User:Ed_Poor/hour&action=edit


Version: unspecified
Severity: enhancement

Details

Reference
bz5733

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:11 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz5733.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

You realise that {{CURRENTMINUTE}}, in particular, would be subject to being
cached quite significantly?

How is that different from {{CURRENTTIME}}?

Wiki.Melancholie wrote:

See also: Bug 366 comment #11 and bug 366 comment #12 (workaround used on fr.wp)

robchur wrote:

(In reply to comment #2)

How is that different from {{CURRENTTIME}}?

{{CURRENTTIME}}, at least, has other elements in output which make it
semi-useful, cached or no. Adding a magic word which we know will be rendered
out of date via caching seems a little stupid to me.

(In reply to comment #4)

{{CURRENTTIME}}, at least, has other elements in output which make it
semi-useful, cached or no. Adding a magic word which we know will be rendered
out of date via caching seems a little stupid to me.

The functionality of {{CURRENTHOUR}} + {{CURRENTMINUTE}} would be a superset of
that of {{CURRENTTIME}}. You can think they all are stupid, but that doesnt
change the fact that people use them. And right now, timezone arithmetics are
done through ugly and inefficient hacks (I wouldnt use the term "workaround" for
a template with 1000+ rows just to increment the hour by one). Cutting the time
to numeric parts which can be passed to the parser functions would be certainly
less stupid than that.

koneko wrote:

a switch with 60*24 possibilities (1440, one per minute of the day) must be a
real ly server-draining, isn't it ?

{{CURRENTHOUR}} introduced in r16058 by Tim Starling

wiki.bugzilla wrote:

reopened, {{CURRENTMINUTE}} is also an issue of this bug and is not implemented yet

robchur wrote:

{{CURRENTMINUTE}} would be worthless if implemented, due to caching. Therefore,
there's little to no point in implementing it.

For understanding purposes: What is the difference in caching between existing
{{CURRENTTIME}}, {{CURRENTTIMESTAMP}} (incl. seconds!) and the requested
{{CURRENTMINUTE}}?

And the folks are very creativ, see [[en:Template:CURRENTMINUTE]] and
[[de:Template:CURRENTMINUTE]] ;-) Which method is more expensive?

robchur wrote:

CURRENTTIME and CURRENTTIMESTAMP are also used for substitution; other
information comes out of those variables which is not so adversely affected by
caching.

(sigh) And it's resorted to "threatening" us with "expensive" templates?
Describe an example of use of a CURRENTMINUTE magic word where caching isn't an
issue, aside from substitution.

Introuducing hundreds of different magic words for time is a waste of time. We
should just introduce a {{#time}} function which does everything, see my comment
on bug 7114. {{CURRENTMINUTE}} would simply be {{#time:i}}. {{CURRENTHOUR}} would
be {{#time:H}}.

robchur wrote:

That would be the best solution; it stops us filling up our codebase with
useless junk, and if the users want to "dynamically" use {{#time:i}}, they can
waste their time with it.

ayg wrote:

*** This bug has been marked as a duplicate of 7116 ***

sebmol wrote:

{{#time:}} has been implemented and should cover all scenarios discussed herein.
Caching will still invalidate many instances where this function would be useful.