Template talk:CURRENTSECOND

This template was considered for deletion on 2006 June 15. The result of the discussion was "keep".

This template was considered for deletion on 2016 September 4. The result of the discussion was "keep".

Comments[edit]

-- Omniplex 19:21, 19 June 2006 (UTC)[reply]

Copied remark from closed TFD discussion: I still don't 'get' the underlying concern here, but the current version of this (and the hour/minute templates) seems fine. --CBD 12:24, 19 June 2006 (UTC)

The underlying concerns are

(1) potential race conditions near hh:mm:59 if you use more than one current variable in a template. You tested it 2000 times and never got it, so far it's fine, and for a second it's also harmless, 59 or 00, who cares, unless something breaks horribly if it's not in chronological order.

(2) for a year it's also harmless because it's unlikely, 2000 tests = 2000 years. For an hour it can be bad, you'd be off by one hour if it hits you.

(3) 0expr: might add a leading zero to an expected result 9, where the actual result (same expression with current variables evaluated twice) is 10. Getting 010 intead of 10 might be harmless, only a broken link or similar, but it could take some time for folks trying to find this bug. It's just a big nono to evaluate current timestamps more than once, the proper way is to get it once, and then parse it as needed, instead of using various moving targets. For examples see m:Template:dectime and its siblings, they all go through Timestamp2MJD if they operate on the timestamp "now".

(4) is the usual AUM consideration, templates using templates using other templates are expensive. Slow. Offering various attack vectors. Limiting them is good. In theory you can "copy" the code of CURRENT hh / mm / ss by say {{subst:CURRENTSECOND}} into another template. The result is not pretty, but less expensive. -- Omniplex 19:41, 19 June 2006 (UTC)[reply]

Items 1-3 are predicated on the possibility of two time related 'magic words' within a single evaluation returning results one or more seconds apart (and that difference being at the minute, hour, day, month, or year rollover point for those values)... which I have been unable to actually generate in several tests. Even assuming that it might be more common if the site were running very slowly I still think it would rarely have any significant impact. For instance, if it took place one time in a hundred (which by all my tests it doesn't come anywhere close to) then an evaluated minute would be off one time in 6,000... an hour once in 360,000... et cetera. The hour used by Wikipedia being off once every third of a million times it is calculated would be a miniscule anomaly... if it happens at all.

As to item 4 - I consider the 'AUM server load' concerns largely fiction based on Brion's statements that it is not significant and we should not worry about it. Even if there is some impact greater than the nanosecond range, 'CURRENTTIMESTAMP' has allowed the evaluation of 'hour' and 'minute' to change from a massive switch to a simple expression... which presumably saves more nanoseconds than are theoretically lost by one evaluation formula vs another. --CBD 21:51, 19 June 2006 (UTC)[reply]

Yes, let's say that 1 - 3 are a calculated risk - I still prefer to avoid it where possible, but for an encyclopedia where the most critical application is a "dated cat-empty" process or similar it's less important.

For 4 both Brion and Rob said in the pump that anybody using {{Tl}} should be booted from the project IIRC. And some "week date" templates on Meta are horribly slow. It also makes me nervous if a template pulls tons of other templates, all of them offering interesting ways for vandals to cause havoc. A long and convoluted template (as long as somebody can fix it if necessary) is probably "better" (wrt performance) than an elegant set of short templates calling each other. Check out m:Template:sttnw, it takes ages. -- Omniplex 09:17, 20 June 2006 (UTC)[reply]

If a template isn't noticably slow or transcluded onto thousands of pages I don't worry about it. I suspect the latter is the concern with {{Tl}}... which I actually use all the time (including just there), but properly substituted the way it is supposed to be. When I was working on Julian date math there was a noticable slowdown with the multi-template version so I combined it into a single template (which is nearly indecipherable), but conversely to speed up the evaluation of {{ME-ref}} I split it out to sub-templates. For this template any difference between the two evaluation methods is too small to detect and thus I'd generally go with the 'easier to understand' method, but I don't think it is a big deal either way. --CBD 12:58, 20 June 2006 (UTC)[reply]

This template is very useful. --Meno25 15:12, 26 November 2006 (UTC)[reply]