Template talk:Signpost/Deadline

"always update both"

Re "always update both": Why do we even need two completely separate sets of deadlines (draft/non-draft)?

Also, while we are at it, why does it require us to specify the date of the previous issue? (twice, and separately from Wikipedia:Wikipedia Signpost/Templates/Issue which already contains that date)

This template quite complicated and confusing, not to speak of bugs. (The other day I spent some time trying to find out why its external link to worldtimeserver.com was always pointing to the wrong time, and ended up removing it until someone can fix it.) It also lacks any documentation. So we should embrace opportunities to simplify it.

Regards, HaeB (talk) 02:53, 2 August 2022 (UTC)

"Why do we even need two completely separate sets of deadlines (draft/non-draft)?"

Because things display differently on drafts than the newsroom. If you have a way to handle both with one update, feel free to suggest improvements.

"Why does it require us to specify the date of the previous issue?"

Omitting them causes template errors. It's an issue with the other templates used for this one. It's used to calculate the ammount of time from the previous issue to the current issue to create a % value. For instance, if the last issue is on July 8, and the next issue is planned for July 20, that's a 12 day period. If 6 days remain, you're at 50%. If the last issue was instead on July 2, that would be a 18 day period, and 6 remaining days would be 33%.

This could be automated with

• {{#time: Y: {{Wikipedia:Wikipedia Signpost/Templates/Issue|1}}}}
• {{#time: m: {{Wikipedia:Wikipedia Signpost/Templates/Issue|1}}}}
• {{#time: d: {{Wikipedia:Wikipedia Signpost/Templates/Issue|1}}}}

In the relevant fields, but that makes the code a bit ugly to read.

"its external link to worldtimeserver.com was always pointing to the wrong time"

I'll investigate. Fixed.

Headbomb {t · c · p · b} 03:31, 2 August 2022 (UTC)

makes the code a bit ugly to read is a very weak argument against an improvement that saves a lot of recurring manual work and potential for error. In any case, JPxG has now implemented such a change. Regards, HaeB (talk) 08:28, 27 February 2024 (UTC)

DRY version

So, I have a version of this template in the sandbox that requires only one set of date/time parameters, and eliminates the "always update both" issue mentioned above. My sandbox version passes all of the testcases.

Here's how it works (and I suppose this also constitutes a caveat): A single {{Signpost/Deadline/core}} transclusion is created, with all of its parameters set, and that transclusion is used as the unnamed argument to another template. (I've already created that as {{Signpost/Deadline/draftwrap}}.) The wrapper is also passed the value of {{{draft}}}, and uses it to decide whether or not to wrap a {{notice}} box around the {{Signpost/Deadline/core}} transclusion passed to it.

If {{{draft}}} is set to something (anything), it just outputs {{{1}}} directly. But with no {{{draft}}} value, it instead forwards {{{1}}} to a {{notice|1={{{1}}}}} transclusion. It therefore does add an extra transclusion to every use of {{Signpost/Deadline}}. Actually, two extra transclusions, since I use {{ifnotempty}} to evaluate {{{draft}}}.

Personally I think it's more than worth the extra transclusions, if it will let us avoid the double-parameter "always update both" tedium. But I'll let the community decide if you agree. FeRDNYC (talk) 14:49, 6 November 2022 (UTC)

@Headbomb, HaeB, JPxG, Bluerasberry, Bri, and Smallbones: Pinging Signpost editorial, and participants in the previous discussion. Take a look if this interests you, apologies for the distraction if not.

Compare the source of {{Signpost/Deadline}} with the source of {{Signpost/Deadline/sandbox}}. Both achieve the same output in all testcases, but I know which one I'd rather have to keep updating. (However, also note the caveat about increased transclusion count, above.) FeRDNYC (talk) 14:59, 6 November 2022 (UTC)

• Support change The one which is simpler to use is better. The extra transclusion is not a burden. Thanks for developing it! Bluerasberry (talk) 15:03, 6 November 2022 (UTC)
• Sure, if it works, it works. Headbomb {t · c · p · b} 15:31, 6 November 2022 (UTC)
• Support new template: simpler is better both for users and maintainers. ☆ Bri (talk) 17:10, 6 November 2022 (UTC)

Good enough for me! Sandbox code applied to live {{Signpost/Deadline}}. Let me know if you spot any issues with transclusions of the new code. FeRDNYC (talk) 17:35, 6 November 2022 (UTC)

Oh, and I'd meant to ask: Does anyone know of any project documentation, checklists, etc. that reference the template, and should be updated to reflect the changes? I'll try to look through the What links here? for the template, but that gets kind of buried under all the transclusions. (Which also register as links, because it displays a {{navbar}} in non-draft mode.) FeRDNYC (talk) 17:40, 6 November 2022 (UTC)

None here either it seems, so we should be good.

Apropos, I have added a mention of the template to Wikipedia:Wikipedia_Signpost/Newsroom/Resources#Publication. Regards, HaeB (talk) 02:47, 7 November 2022 (UTC)

Looks good. Great job! This removes a significant nuisance. Regards, HaeB (talk) 02:47, 7 November 2022 (UTC)

My basic assumption is that all Signpost templates are a total mess because they weren't designed so much as they were accumulated over the course of seventeen years whenever somebody wanted a new feature. Accordingly, we end up with stuff like this. I haven't familiarized myself with the whole ecosystem of how the hell this specific template interacts with everything else, but if you have, then please go HAM with this because the new source code looks far better than the old. jp×g 21:47, 6 November 2022 (UTC)

On that note, if you have spelunked down into the code, I'd recommend typing up some notes on how it works in a documentation page, and a brief explanation of the template's purpose at Wikipedia:Wikipedia_Signpost/Technical. We may not be able to avoid the mess, but we can protect future generations... including, perhaps, ourselves in a few months ;^). jp×g 21:47, 6 November 2022 (UTC)

@JPxG: Heh. Well, I basically did a full breakdown of how {{Signpost/Deadline/core}} works, in the collapsed details block at the end of the proposal immediately below here. Serendipity! FeRDNYC (talk) 23:04, 6 November 2022 (UTC)

Apropos, does Wikipedia:Wikipedia Signpost/Newsroom/Deadline/core do anything, or can it be deleted? Regards, HaeB (talk) 02:47, 7 November 2022 (UTC)

It might do something, but it definitely isn't being used for anything. The "what links here" list is two pages: This one, and Wikipedia talk:Wikipedia Signpost/Archive 8. I suppose info on what it was originally meant to do might be found at the latter, should anyone care enough to investigate. I don't, really, because it clearly has no current purpose. #KillItWithFire. FeRDNYC (talk) 05:11, 7 November 2022 (UTC)

JPxG has since added a documentation page claiming under "Usage" that this template is "Transcluded at Wikipedia:Wikipedia Signpost/Newsroom/Tasks." But I don't actually see it transcluded there. @JPxG: Can you clarify? Per FeRDNYC's comment above we may actually want to delete this as unused. Regards, HaeB (talk) 05:04, 25 May 2023 (UTC)

I have no idea what the hell I was smoking when I wrote that. It's not transcluded by Tasks, and Tasks hasn't been edited in a very long time. Speaking of which, what the hell does Tasks do? Is it current? I don't see much in the WLH and the article links in it are from 2009. jp×g 08:17, 25 May 2023 (UTC)

Thanks - an insource search turns up no further references to Wikipedia:Wikipedia Signpost/Newsroom/Deadline/core either. Except this 2015 discussion where someone already suggested to MfD it, and someone else objected that even unused templates should rather just be marked as deprecated, arguing that Things that may seem useless now may come in handy in the future. That kind of logic can become dangerous, but for now I followed this advice and marked the template as deprecated.

Regarding Wikipedia:Wikipedia Signpost/Newsroom/Tasks, I see it had in fact been marked as deprecated in 2015, too. But then Zarasophos un-deprecated it again in 2018, apparently as part of Wikipedia_talk:Wikipedia_Signpost/Archive_12#Process_makeover. Zarasophos, do you happen to have any insight on whether and how it was used, and whether that use is still relevant? Regards, HaeB (talk) 06:05, 26 May 2023 (UTC)

If we don't hear anything further on this, I am strongly in favor of continuing to delete the random old bullshit templates that aren't used for anything. This was a project I made some headway on earlier this year (see Wikipedia:Wikipedia_Signpost/Omni-index/Linkshere for tables that sort these template by links, redirects, transclusions, transcluded redirects, etc). jp×g 08:16, 26 May 2023 (UTC)

Date argument formatting

Another question unrelated to the previous code change, for anyone who has to update this template and has an opinion. Currently, the interior transclusion (the one that has to be updated) looks like this:

{{Signpost/Deadline/core|draft={{{draft|}}}|short={{{short|}}}
<!-- Previous issue--> |previous-year=2022 |previous-month=10 |previous-day=30
<!-- Next issue    --> |next-year    =2022 |next-month    =11 |next-day    =27
<!-- Deadline time --> |next-hour=23 |next-minute=00 }}

I realized that, with some fairly simple code changes to {{Signpost/Deadline/core}}, I can make it cleanly support full-date parameters instead, so that the transclusion would instead look like this:

{{Signpost/Deadline/core|draft={{{draft|}}}|short={{{short|}}}
|previous-issue=2022-10-30
|    next-issue=2022-11-27
<!-- Deadline time --> |next-hour=23 |next-minute=00 }}

(I might even be able to do something with the time, so that it can be simply |deadline-time=23:00. I have to look into that a bit more, so no promises.)

To me, the second option seems infinitely preferable, it's not even a contest which one I'd rather have to use. Even if the format were so fragile that it would break unless I typed exactly YYYY-MM-DD, I would rather always make sure to do that, than have to deal with the separate arguments.

But ultimately, I'm not the one who has to maintain the template arguments, so my preferences are completely irrelevant. So, for those who do have to maintain the template arguments: Would supporting single-parameter date arguments, instead of the separated components, improve things for you? Or, do you think-it's-fine/actually-prefer the way things currently work?

Notes

Expand for detail on how I'd propose to achieve this

(I should give fair warning to the curious: This is rather long, and a bit stream-of-consciousness. Ideas for further improvements were occurring to me even as I was in the middle of explaining a previous idea I'd just decided to abandon.)

Use YYYY-MM-DD parameter directly, where possible

Currently, {{Signpost/Deadline/core}} uses its separated arguments to builds some transclusions of both Bri's {{User:Bri/DateCountdown}} and {{countdown}}, transforming the input arguments in different ways to construct the parameters for those transclusions.

A good chunk of those transformations are date math powered by the {{#time:}} parser function, and it was reading that code that made me realize that there's really no point to requiring all those separated args. The {{#time:}} calls all end up reconstructing the ISO-8601 (YYYY-MM-DD) style date strings in order to use them as arguments to #time.

The code is full of things like this:

{{#time: Y|{{{previous-year}}}-{{{previous-month}}}-{{{previous-day}}} - 1 day}}|{{#time: n|{{{previous-year}}}-{{{previous-month}}}-{{{previous-day}}} - 1 day}}|{{#time: j|{{{previous-year}}}-{{{previous-month}}}-{{{previous-day}}} - 1 day}}

Those parser function calls all do calendar math to find the date value of the previous issue date in YYYY-MM-DD form, minus 1 day. There's three of them, because it separately extracts the year, month, and day values as arguments to Bri's template.

But if the code is going to reconstruct a YYYY-MM-DD-format date anyway, why not just provide it in that form to start with? That code can become simply this, with equivalent results:

{{#time: Y|{{{previous-issue}}} - 1 day}}|{{#time: n|{{{previous-issue}}} - 1 day}}|{{#time: j|{{{previous-issue}}} - 1 day}}

Reconstruct separate components using #time

Of course, then there are other parts of the code, where individual date components are passed as arguments instead. But the code I just discussed already provides a solution for that: #time can be used to extract components from a date string. So, the parts of the current code that look like this:

{{countdown |year = {{{next-year}}} |month = {{{next-month}}} |day = {{{next-day}}} |... }}

would instead become:

{{countdown |year = {{#time: Y|{{{next-issue}}}}} |month = {{#time: n|{{{next-issue}}}}} |day = {{#time: j|{{{next-issue}}}}} |... }}

Exact same results, but with a single |next-issue=YYYY-MM-DD parameter as input.

Now, there are a lot of places where parameters like {{{next-year}}} and etc. are passed directly, which means converting them would create a lot more invocations of #time. Quite possibly, too many for the server to handle without going over the complexity limits for the parser and erroring out during processing.

But I have a solution for that, too. If necessary for complexity reasons, or simply because we agree it's safer this way regardless, I can insert a wrapper template around the {{Signpost/Deadline/core}} transclusion the same way I did with {{Signpost/Deadline/draftwrap}}.

Add a wrapper template to do the argument processing (one time only)

A theoretical {{Signpost/Deadline/datewrap}} would replace the {{Signpost/Deadline/core}} transclusion, accepting single-argument YYYY-MM-DD dates and pre-exploding them once in the process of building the actual {{Signpost/Deadline/core}} transclusion.

With this approach, the code changes inside {{Signpost/Deadline/core}} would actually be much smaller, although it would make sense to pass in both the exploded and unexploded date parameters as separate arguments and still use the combined version where appropriate.

In this version, {{Signpost/Deadline}} would look largely the same as my proposed new-code example, except that would be calling {{Signpost/Deadline/datewrap}} instead. That template would simply be this:

{{Signpost/Deadline/core
|previous-issue={{{previous-issue|}}}
|previous-year={{#time: Y|{{{previous-issue|}}}}}
|previous-month={{#time: n|{{{previous-issue|}}}}}
|previous-day={{#time: j|{{{previous-issue|}}}}}
|next-issue={{{next-issue|}}}
|next-year={{#time: Y|{{{next-issue|}}}}}
|next-month={{#time: n|{{{next-issue|}}}}}
|next-day={{#time: j|{{{next-issue|}}}}}
|other|args}}

That way, the separation of {{{previous-issue}}} into {{{previous-year}}}, {{{previous-month}}}, and {{{previous-day}}} only happens one time, and the extracted values are used multiple times inside {{Signpost/Deadline/core}}.

Let the wrapper construct even more useful parameters, for a streamlined /core

Ooh! In fact, since the YYYY-MM-DD form of the date is only used in the #time calls to subtract one day and split out the components, I could move that code into the wrapper as well, and make the /core code cleaner by using the pre-separated values. IOW, the wrapper code becomes:

{{Signpost/Deadline/core
|writing-previous-year={{#time: Y|{{{previous-issue|}}} - 1 day}}
|writing-previous-month={{#time: n|{{{previous-issue|}}} - 1 day}}
|writing-previous-day={{#time: j|{{{previous-issue|}}} - 1 day}}
|previous-year={{#time: Y|{{{previous-issue|}}}}}
|previous-month={{#time: n|{{{previous-issue|}}}}}
|previous-day={{#time: j|{{{previous-issue|}}}}}
|writing-next-year={{#time: Y|{{{next-issue|}}} - 1 day}}
|writing-next-month={{#time: n|{{{next-issue|}}} - 1 day}}
|writing-next-day={{#time: j|{{{next-issue|}}} - 1 day}}
|next-year={{#time: Y|{{{next-issue|}}}}}
|next-month={{#time: n|{{{next-issue|}}}}}
|next-day={{#time: j|{{{next-issue|}}}}}
|other|args}}

The "writing-*" parameters would then eliminate all of the #time invocations in {{Signpost/Deadline/core}}, replacing them with simple drop-ins of {{{writing-previous-year|}}} and etc.

FeRDNYC (talk) 22:59, 6 November 2022 (UTC)

The other option would be to write a Lua module to replace all of this nonsense, and TBH I am not completely opposed to going that route instead. As much as I dislike Lua as a language, it still beats byzantine template invocations like these. FeRDNYC (talk) 23:09, 6 November 2022 (UTC)

Sounds good to me - a single YYYY-MM-DD argument should be easier to read and enter. (Not a huge difference though, so don't feel obliged to invest a lot of time..) Regards, HaeB (talk) 02:56, 7 November 2022 (UTC)

New sandbox version: Human-friendly date support

OK, I now have a version of the template in Template:Signpost/Deadline/sandbox that uses my newly-added Template:Signpost/Deadline/dateswrap subpage wrapper around Template:Signpost/Deadline/core instead of calling it directly.

Whereas /core has a rigid set of fiddly parameters, /dateswrap requires only two. Technically they can be in any format parseable by the #time parser function, but the recommended formats are:

• |previous-issue=YYYY-MM-DD
• |next-issue=YYYY-MM-DD HH:NN UTC

I folded the former |next-hour=} and |next-minute= parameters into |next-issue= along with the date pieces, so the full time and date of the release deadline is defined by a single template parameter. (|previous-issue= also accepts time values, but they'll be silently ignored.)

Again, the sandbox version passes all testcases. Looking at the NewPP limit report embedded on both pages, the additional call to /dateswrapper has a shockingly small effect on the transclusion stats. The sandbox version does run slower, as expected given all the additional work it does, but we're talking page generation times of 163ms (new) vs. 151ms (old). That's a difference of under 10%, barely discernible from the server's normal background fluctuations. Even the fact that /dateswrap adds 16(!) calls to the #time: parser function (used to process the input parameters and extract individual date/time components) has an apparently-negligible impact, which is a surprise (to me, at least).

This is without even making any changes to /core yet, so a lot of the work done in /dateswrap is currently both ignored by, and then repeated in, the /core template itself. Once these changes are live and I've stripped /core of all the work that can now be offloaded into /dateswrap, it'll probably result in a net performance gain. (Not that the current templates' performance requires any improvement, or is even remotely a concern.)

I'll let it sit for a bit so people have a chance to check it out and kick the tires. If nobody has any concerns, once it's live I can update the docs and start streamlining /core to use the additional parameter values passed to it by /dateswrap instead of generating them all itself. FeRDNYC (talk) 09:52, 9 November 2022 (UTC)

Whereas /core has a rigid set of fiddly parameters, /dateswrap requires only two. Slightly inaccurate, technically. There are three additional parameters which can be used in {{Signpost/Deadline}} transclusions: |short=, |draft=, and |refresh=. Those also get passed to /dateswrap, which in turn passes them along unmodified to /core. FeRDNYC (talk) 09:59, 9 November 2022 (UTC)

@Headbomb, HaeB, JPxG, Bluerasberry, Bri, and Smallbones: Should've flagged the usual suspects to this one, as well. Better late than never?

Oh, and I left out one important caveat regarding |next-issue= : while it will accept a timezone identifier along with the date and time values, until the /core subtemplate is updated it'll ignore that and continue to hardcode UTC like it always has. (Once it's updated to use the new parameters /dateswrap generates for it, defining the deadline in terms of some other timezone's clock will be possible, although UTC will always be the default, the fallback, and the recommended timezone for specifying time values. FeRDNYC (talk) 17:10, 10 November 2022 (UTC)

Nice! I would say go ahead and implement it. Even if there's an unforeseen problem (which doesn't seem likely) we can just roll it back, and it doesn't seem like it would affect reader-facing pages anyway. Thanks for all your work on this!

While we are at it, this might be a great time to also eliminate the necessity to manually update the previous-issue date, since that information is already contained in Wikipedia:Wikipedia Signpost/Templates/Issue and can be obtained from there (see discussed above). If we want to get fancy, we could then even use it to have the template detect when the next-issue time has become obsolete after publication, and display a "to be determined" message or such. Regards, HaeB (talk) 06:24, 11 November 2022 (UTC)

I've been thinking about the question of |next-issue= management. Right now, the official statement is that Template:Signpost/Deadline is the canonical single source of what the deadlines actually are (i.e. editing this template changes the deadlines). But I think it might be worth rethinking that, and taking a page from how software release information is managed @ MediaWiki.

One of the big advantages to single-parameter inputs for the dates is that they could (easily) receive other template calls as arguments. (As opposed to the previous split-args version, where that would've been a giant PITA.) With the new code we could indeed use |previous-issue={{Wikipedia:Wikipedia Signpost/Templates/Issue|3}} instead, and never have to update it by hand ever again.

The only reason I'm slightly reluctant to do that is the unfathomable terribleness of that template's "interface". The magical random |1=1, |1=2, |1=3 arguments... I suppose there might've been some justification for that when a bot was handling publishing duties (though I doubt it), but that bot's been gone for 7 years and as an interface for humans, it's the absolute pits.

So, I'd like to do something like that, but using a template call that's not esoteric magic like {{Wikipedia:Wikipedia Signpost/Templates/Issue|3}} and doesn't suck as hard. And while we're mucking about, why don't we also move the next-issue information out of the Deadline template and into a central location where all publication data is managed, so that NO part of the Deadline template ever needs manual updating, because its parameters are set by two calls to other templates?

As an example of this type of organization, MW has a whole raft of mw:Category:MediaWiki version information templates that all return just one tiny piece of well-formatted data about a release. There are templates for {{mw:MW stable release number}}, {{mw:MW stable release date}}, {{mw:MW stable release link}}, etc.

Those templates are all implemented as {{#invoke:}} calls to mw:Module:Version, and they produce rigidly-formatted data because they're used everywhere across the MediaWiki download pages, version history, documentation, and etc. so that version information on project pages is always current.

I don't know that the Signpost issue-publication data requires a backend module to produce the data required. I think we could probably get away with a few templates named things like {{Signpost next issue deadline}}, {{Signpost current issue volume}}, {{Signpost current issue number}}, {{Signpost current issue volume-number}}, {{Signpost current issue date}}, etc. (And maybe {{Signpost next issue volume}} and etc., if we found a need for them.)

Those templates would all source the values used in their output from some central location (maybe even *shudder* Wikipedia:Wikipedia Signpost/Templates/Issue), and they'd be what gets used anywhere we need one of those values in a particular format. The actual source data only needs to be managed in one place, and doesn't necessarily have to have the same format as what's output by the data templates (which can convert it if necessary), so the raw info can be kept in whatever format/organization makes sense for Signpost editorial.

Heck, if we did a full set of {{Signpost next issue deadline year}}, {{Signpost next issue deadline month}}, etc. — or made the deadline template accept optional args like {{Signpost next issue deadline|month}} to extract them — those could be used directly inside {{Signpost/Deadline/core}}, I could drop {{Signpost/Deadline/dateswrap}} completely (its only purpose is to extract those values), and {{Signpost/Deadline}} wouldn't even need to have any date parameters in it. FeRDNYC (talk) 13:05, 12 November 2022 (UTC)

The new version of {{Signpost/Deadline}} which uses {{Signpost/Deadline/dateswrap}} is now live, and {{Signpost/Deadline/core}} has been updated to make use of the new variables created by /dateswrap, it no longer contains any {{#time:}} parser function calls.

As predicted, removing the redundant processing of the time values dropped the execution times of the whole stack back down below the starting point; the use of /dateswrap is an overall improvement in efficiency. Probably because it avoids reassembling date strings from parameters just to explode them out again.

IOW, doing this:

|writing-next-year={{#time: Y|{{{next-issue|}}} - 1 day}}
|writing-next-month={{#time: n|{{{next-issue|}}} - 1 day}}
|writing-next-day={{#time: j|{{{next-issue|}}} - 1 day}}
|writing-previous-year={{#time: Y|{{{previous-issue|}}} - 1 day}}
|writing-previous-month={{#time: n|{{{previous-issue|}}} - 1 day}}
|writing-previous-day={{#time: j|{{{previous-issue|}}} - 1 day}}

and using those variables turns out to be more efficient than setting separate variables and doing this:

<!--Previous issue date using #time to reformat it:-->
{{#time: Y|{{{previous-year}}}-{{{previous-month}}}-{{{previous-day}}} - 1 day}}
|{{#time: n|{{{previous-year}}}-{{{previous-month}}}-{{{previous-day}}} - 1 day}}
|{{#time: j|{{{previous-year}}}-{{{previous-month}}}-{{{previous-day}}} - 1 day}}
|<!--Current deadline:-->
{{#time: Y|{{{next-year}}}-{{{next-month}}}-{{{next-day}}} - 1 day}}
|{{#time: n|{{{next-year}}}-{{{next-month}}}-{{{next-day}}} - 1 day}}
|{{#time: j|{{{next-year}}}-{{{next-month}}}-{{{next-day}}} - 1 day}}

That feels unsurprising, but it's still good to have confirmation. FeRDNYC (talk) 04:24, 13 November 2022 (UTC)

A strangeness I have noticed

Right now, the time, UTC, is a little past midnight (00:33 on 16 October). The time param in this template is set to be 01:00, on 16 October. So -- as expected -- the thing says "27 minutes to publication". Yet when I open any of the templates in an incognito window, it bizarrely says there are 13 hours and 27 minutes left until publication. Whuh? I'm in California, so it's currently 17:35, which means that 01:00 on 16 October in my time is not 13 hours away. I've purged the caches et cetera so I don't think this is the issue. What the heck is going on? jp×g 00:35, 16 October 2023 (UTC)

This is a longtime problem with this template which is most likely due to MediaWiki's overly aggressive server-side caching for anonymous readers (see Help:Purge about caching in general; the discussions at phab:T119366 contain some information that is more directly relevant to this particular issue).

I wouldn't actually mind removing the timer altogether for this reason.

Regards, HaeB (talk) 03:26, 23 October 2023 (UTC)

Time of day for the previous issue?

@JPxG: What was the rationale for adding a time of day to the previous-issue parameter in Special:Diff/1183371029? Don't we only need the date of its publication (rather than the exact time)? Regards, HaeB (talk) 14:39, 22 December 2023 (UTC)

None -- the template was acting really weird and I was trying random stuff to see if it had any effect. It ended up being unrelated to that though. jp×g🗯️ 03:07, 23 December 2023 (UTC)