Jump to content

Template talk:Date

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Template talk:DATEtoMOS)

Option for linked date

[edit]

Currently all dates are being delinked by bot. There may however be a few cases where a date should remain linked. A solution might be to add a parameter to this template to include a link. So {{date|11 January 2009|link}} would convert it to "[[11 January]] [[2009]]" turning up as 11 January 2009 in the article. The bot would not see this as a linked date and leave it alone. Combination parameters like dmylink, mdylink, isolink etc could be made as well. −Woodstone (talk) 23:18, 10 January 2009 (UTC)[reply]

What you want is already implemented, e.g. {{date|11 January 2009|ldmy}} emits 11 January 2009
Cf. the <date formatting style> options in the "syntax" section in the template documentation for details. -- Fullstop (talk) 00:49, 11 January 2009 (UTC)[reply]
However, see Requests for arbitration#Date delinking. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:17, 11 January 2009 (UTC)[reply]
Very good, but requesting the link forces a format choice as well. The combination "lnone" is not present and would be better named "link". It adds the link to whatever input format was given. −Woodstone (talk) 12:53, 11 January 2009 (UTC)[reply]
Its not possible (for a template) to reliably detect what the input format is. -- Fullstop (talk) 15:45, 11 January 2009 (UTC)[reply]
That sounds strange. How is the template able to switch elements around between dmy, mdy and iso without knowing what the input format was? −Woodstone (talk) 17:14, 11 January 2009 (UTC)[reply]
The template doesn't itself switch elements around. It passes the input unmodified to {{#time}}, which is a server function, and which returns the desired part(s) in the desired order.
For example, {{date|<some date>|dmy}} is effectively the same as {{#time:j F Y|<some date>}}.
Similarly, {{date|<some date>|ldmy}} is effectively the same as {{#time:[[:j F]] [[Y]]|<some date>}}.
At the bottom line (i.e. aside from ancillary stuff like error protection etc), what the template is really doing is mapping 'dmy' etc to 'j F Y' etc. -- Fullstop (talk) 17:43, 11 January 2009 (UTC)[reply]

Thanks. That makes sense. You may have seen at Wikipedia talk:Manual of Style (dates and numbers)#Date linking template, that I have proposed to use this template as as escape for the exceptional date links that should not be removed by bots. −Woodstone (talk) 19:24, 11 January 2009 (UTC)[reply]

Ideally this template should be able to handle any date that can be handled by MediaWiki's autoformatting, which includes all dates between 1000 and 9999. If the template did so, then bots could actually wrap all dates without a second thought.
However, this template has an artificial lower limit of 1583. So, for the sake a mere 5 dates that it shouldn't convert, the template ignores the other 212,571 dates that it should convert. Go figure. As Spock would say, "it's not logical, Jim." -- Fullstop (talk) 21:05, 11 January 2009 (UTC)[reply]
Replace...
|{{#ifexpr: {{#time:Y|{{{1|}}} }} < 1582|none}}
with...
|{{#ifexpr: {{#time:Y|{{{1|}}} }} < 1000|none}}
|{{#switch: {{#time:Ynj|{{{1|}}} }}|100031|110031|130031|140031|150031=none}}
...and voila! all but the five potentially-bad March 1s will be converted. -- Fullstop (talk) 21:37, 11 January 2009 (UTC)[reply]
I'll buy that.  Done - that's a much nicer way of doing it than the old method... Happymelon 22:33, 11 January 2009 (UTC)[reply]
Kudos for the quick response. What I hadn't realized before was that the entire switch block is evaluated before the #switch runs. I erroneously assumed that the switches had to be constants, hence the convoluted {{if {{if {{if {{if {{if nest. Its only after I saw your elegant "none" switch that I cottoned on. -- Fullstop (talk) 22:53, 11 January 2009 (UTC)[reply]

I tested the change in one of my sandboxes. I found that dates that exist in the Julian calendar but not in the (proleptic) Gregorian calendar are not reformated to the d mmmmm yyyy format, which is the default format.

Also, the behavior of the template was changed (or an attempt to change it was made) with no corresponding change in the documentation.

Finally, I don't see that this would necessarily solve the problem of linking dates in a way that will not be detected by bots that unlink dates. In the past, there was a desire to always link both the day-month and the year. Now, linking is to be far more selective, so it is likely that in the rare instances a link is a good idea, there will probably be a wish to link the day-month, but not the year, or vise versa. I don't think the date template fully supports, that, does it? --Gerry Ashton (talk) 00:00, 12 January 2009 (UTC)[reply]

After re-reading this, I suspect Happy-melon or Fullstop will say it is working as intended. But the only description of the change in this discussion is "Ideally this template should be able to handle any date that can be handled by MediaWiki's autoformatting, which includes all dates between 1000 and 9999." The dates in my sandbox would be converted by autoformatting if they were linked. If the behavior of the template were intended to do something else, the intended behaviour should be stated. --Gerry Ashton (talk) 00:08, 12 January 2009 (UTC)[reply]
I see that the tempate documentation has been updated. I think it is a terrible idea for a function to exist that has booby traps scattered about the range of allowable inputs. The dates that won't format are just to easy to miss in the documentation. What about the case of the user who initally is able to get away with using the function because none of the dates used in the artilce(s) happen to be one of the 10 booby traps, but later, such a date must be used, so the whole approach has to be reengineered? --Gerry Ashton (talk) 00:27, 12 January 2009 (UTC)[reply]
You mean that on that one date, the user must be careful with how they format the input, because unlike the others the template won't compensate for general laziness? Hardly a "reengineer[ing] the whole approach". It's not like the template eats the content or returns a nonsense value when a "booby trap" date is hit, it just reverts to the exact same situation that would be present if the template wasn't used at all. Happymelon 17:39, 30 January 2009 (UTC)[reply]


Problem if template is only passed a year

[edit]

Hi,

I'm wanting to use the date template within a different template (citation/core), but if I do so, it will sometimes be passed partial dates. At present {{date|1901}} renders as 1901. This is because {{[[Template:#time|#time]]}} recognises any 4-digit string as a time if it can. I think I've fixed this in {{Date/sandbox}}; could someone familiar with this template confirm that this won't introduce any errors?

Thanks,

Martin (Smith609 – Talk) 13:57, 30 January 2009 (UTC)[reply]

{{editprotected}}

  1. Simple solution:
    Replace
      |{{#switch: {{#time:Ynj|{{{1|}}} }}|100031|110031|130031|140031|150031=none}} <!--
    --> = {{{1|}}}<!-- error or "none", so no formatting -->
    With
      |{{#switch: {{#time:Ynj|{{{1|}}} }}|100031|110031|130031|140031|150031=none}}
      |{{#ifeq:{{{1|}}}|{{#expr:0+({{{1|0}}})}}|none}} <!--
    --> = {{{1|}}}<!-- error or "none", so no formatting -->
    This should cause any input that is a plain number (e.g. [-]1234[.567]) to be handled as invalid input.
    The '0+()' is needed to correctly handle a provided-but-empty first param (e.g. in {{date||}})
  2. A version that treats year-only as valid input (at User:Fullstop/Sandbox/T1).
    Examples: (all valid values as links to show that processing happens; unprocessed remain black)
    {{T1|1985|ldmy}} => 1985
    {{T1|1901|ldmy}} => 1901
    {{T1|1985.123|ldmy}} => 1985.123 (no change because error)
    {{T1|-1985|ldmy}} => -1985 (no change because error)
    {{T1|1985-10-21|ldmy}} => 21 October 1985
    {{T1|1901-10-21|ldmy}} => 21 October 1901
    {{T1|October 21, 1985|ldmy}} => 21 October 1985
    {{T1|21 October 1985|ldmy}} => 21 October 1985
    {{T1|October 21|ldmy}} => 21 October
    {{T1|21 October|ldmy}} => 21 October
    {{T1|October|ldmy}} => October
    {{T1||ldmy}} => 2 December
While the second solution treats year-only values as valid input, the first solution is significantly simpler, and 10 lines shorter.
Take your pick. ;) -- Fullstop (talk) 17:27, 30 January 2009 (UTC)[reply]
(ec, haven't looked at Fullstop's code properly)Been there, tried both, don't you remember, Fullstop?
{{date/sandbox|2009-01-30}}30 January 2009

(update)

as expected - I like the way Martin's method catches this false positive.
{{date/sandbox|20090130172000}}30 January 2009

(update) , which is the output from {{subst:CURRENTTIMESTAMP}}

However, we should be able to work around that, as no other input can be interpreted as a fourteen-digit number. If you can do it reliably, I'll put it in. Happymelon 17:33, 30 January 2009 (UTC)[reply]
Input {{date}} {{date/sandbox}} {{T1}}
1985 1985 1985

(update)

1985
1901 1901 1901

(update)

1901
1985.123 1985.123 1985.123

(update)

1985.123
-1985 -1985 -1985

(update)

-1985
1985-10-21 21 October 1985 21 October 1985

(update)

21 October 1985
1901-10-21 21 October 1901 21 October 1901

(update)

21 October 1901
October 21, 1985 21 October 1985 21 October 1985

(update)

21 October 1985
21 October 1985 21 October 1985 21 October 1985

(update)

21 October 1985
October 21 21 October 21 October

(update)

21 October
21 October 21 October 21 October

(update)

21 October
October October October

(update)

October
2 December 2 December

(update)

2 December
20090130175933 30 January 2009 30 January 2009

(update)

30 January 2009
20090130 20090130 20090130

(update)

20090130
200901301759 200901301759 200901301759

(update)

200901301759
19850521175933 21 May 1985 21 May 1985

(update)

21 May 1985
19850521 19850521 19850521

(update)

19850521
198505211759 198505211759 198505211759

(update)

198505211759
2007b (Harvard ref) 2 December 2 December

(update)

2 December

(ec)

Oh, it was 20090130172000 was it? I thought the problem lay with 2009-01-30, which also evaluates to a numeric expression.
Anyway, 20090130172000 is not correctly handled by date either. {{date|20090130172000|ldmy}} => 30 January 2009
Same result with T1: {{T1|20090130172000|ldmy}} => 30 January 2009
So, obviously that issue needs to be resolved independently. I'm on it now. -- Fullstop (talk) 18:05, 30 January 2009 (UTC)[reply]
Huh???!!! Look at the last row of the table above! -- Fullstop (talk) 18:08, 30 January 2009 (UTC) Never mind it was a missing param in that row. -- Fullstop (talk) 18:11, 30 January 2009 (UTC)[reply]
Indeed, it seems it interprets that format as lacking a year: {{#ifeq:{{#time:Y|20090130175933 2008}}{{#time:Y|20090130175933 2004}}|20082004|yes|no}} → yes. Since there's sod all we can do with lone years other than link them, I can't see very much benefit to putting them through the whole formatting mangle. Happymelon 18:21, 30 January 2009 (UTC)[reply]
I'm on it. Question: In addition to 20090130175933, do we want to support A) '20080130' B) '200801302359' C) '2008.123' ? -- Fullstop (talk) 18:36, 30 January 2009 (UTC)[reply]
{{T1|20090130172000|ldmy}} => 30 January 2009 works now. -- Fullstop (talk) 18:39, 30 January 2009 (UTC)[reply]
ps: '20080130' and '200801302359' is also enabled.
No; they're not sensible date formats (in fact it makes more sense to explicitly exclude them). Neither is yyyymmddhhmm without the ss on the end; I think you're getting carried away again :D. One other one we might want to think about is yyyy-mm-ddThh:mm:ssZ, which is the output format from the API. Happymelon 19:44, 30 January 2009 (UTC)[reply]
fine by me. no partials then. -- Fullstop (talk) 19:49, 30 January 2009 (UTC)[reply]

I don't know if this helps, but adding "0:00" to the start of a year forces #time to recognize it as a year instead of a time. For example, {{#time:Y|0:00 1999}} = 1999. So, we should be able to make {{date|1999}} = 1999. —Remember the dot (talk) 20:25, 1 February 2009 (UTC)[reply]

Can we update the template, please? It's holding up edits to other pages. I've only skimmed the above section but could we quickly decide whether fullstop's or my implementation are preferable and move ahead with either of them?
Thanks, Martin (Smith609 – Talk) 17:41, 6 February 2009 (UTC)[reply]

Argh!

[edit]

Trying to keep up with the latest crazy format crisis without string functions is doing my head in! Apparently "2007b" is a common and accepted input to |date= parameters of citation templates when using Harvard referencing. Clearly this should be returned unhandled, but it's currently not:

(update)

I can't think of a way to test for this off the top of my head. Does anyone have any bright ideas? Happymelon 21:00, 9 February 2009 (UTC)[reply]

My solution would be to test the input against all supported formats. If the input is in a supported format, reformat it as requested. If it is not, return it as entered. I know it's tedious to test for every format but I think that's the way we're going to have to go to be reliable. —Remember the dot (talk) 21:08, 9 February 2009 (UTC)[reply]
What exactly do you mean? Do you mean comparing the string entered with the #time: reformatted string for each acceptable format? That's a distinct possibility. Happymelon 21:18, 9 February 2009 (UTC)[reply]
Exactly. This is what Template:ISO date does, and it seems to work well. Its workings were discussed at User talk:Trödel/Archive 11#ISO date template. It would probably be a good idea to create a date-formatting template with Draconian strictness for the input's format, and then create a second date-formatting template that used #iferror to fall back on returning the date as entered. —Remember the dot (talk) 03:49, 10 February 2009 (UTC)[reply]
Citation shouldn't be reformatting user input (at least not in the manner it is doing it now). Moreover, this is {{cite xyz}} crappiness at work, not an issue with citation, and the {{cite xyz}} madness should be reformatting the value passed to core, not delegating the insanity to a level where it didn't previously exist.
Moreover, the reformatting should reformat only if the input matches the yyyy-mm-dd, which is the only format that is deprecated. That infernal DateFormat= parameter is sheer featuritis, and the present clobber-everything with {{date}} not only requires editors to use DateFormat=, but breaks the thus-far perfectly fine use of cleanly formatted dates.
This newly-discovered "problem" is symptomatic of the absolutely uncircumspect approach to forwarding every piece of {{cite xyz}} insanity into Citation/core. Its {{unicite}} through the backdoor and requires both editors and {{date}} to jump through hoops that neither should need to care about. Argh! indeed. -- Fullstop (talk) 23:51, 9 February 2009 (UTC)[reply]
I've provided a fix for {{citation/core}} here. Examples include more "arghs" that {{date}} will never be able to handle, but are perfectly valid dates in a citation. -- Fullstop (talk) 00:59, 10 February 2009 (UTC)[reply]
I've removed the DateFormat parameter from Template:Citation/core, so all citations should be following the DMY format now, which is the standard format for citations even in the United States. I can't think of any instance where we would need to deviate from this format. But looking back over your comment, I'm not entirely sure this is what you wanted. If this starts upsetting people then I'd be happy to pull it back. —Remember the dot (talk) 04:11, 10 February 2009 (UTC)[reply]
DMY is not the standard format for citations, neither in the English Wikipedia nor in the United States. Indeed, no one has the power to set a standard for the United States, so no such standard can possibly exist. Furthermore, the widely-used APA style gives, as an example on page 241, "Kandel, E. R., &Squire, L. R. (2000, November 10)". One counterexample suffices to disprove an absolute statement. --Gerry Ashton (talk) 04:29, 10 February 2009 (UTC)[reply]
Apologies, "standard" was a poor choice of words. Both MLA and Harvard use DMY, don't they? Isn't that what we've been using as well? —Remember the dot (talk) 04:32, 10 February 2009 (UTC)[reply]
Apology rejected now accepted. Thank you for reverting your change. Failure to do so would suggest de-admining would be appropriate. You have no right to impose your style opinions on the whole English Wikipedia by virtue of being an administrator --Gerry Ashton (talk) 04:35, 10 February 2009 (UTC) Revised 04:57 UT.[reply]

I don't have the 15th edition of the Chicago Manual of Style, but according to a summary "Chicago style now prefers full dates American style, in month day, year format. " --Gerry Ashton (talk) 04:50, 10 February 2009 (UTC)[reply]

Interesting. Are there articles here that use the Chicago format? —Remember the dot (talk) 04:56, 10 February 2009 (UTC)[reply]
There is no agreement to use any particular style, other than to use the same style within an article. See WP:CITE. There is no style manual that guides the development of the various cite/citation templates; each bunch of editors of each template do whatever they please. Since scholars who write in a single dicipline probably get the style of their dicipline built into the nerves that control their fingers, I see little hope of getting any one style accepted throughout the English Wikipedia. --Gerry Ashton (talk) 05:03, 10 February 2009 (UTC)[reply]
To answer the question about whether the Chicago Manual is actually used in Wikipedia, I searched for "Chicago Manual" in the talk pages, and found Talk:The Cat and the Canary (1927 film). It uses the Chicago Manual.
But the template will automatically normalize the date format; it doesn't matter what's been drummed into everyone's nerves. The important thing is that we pick a date format for final output and stick to it for our readers' sake. —Remember the dot (talk) 05:27, 10 February 2009 (UTC)[reply]
Some articles do not use templates, so nothing will be normalized. Trying to impose one universal style on these articles will not succeed because the editors who wrote them will want to continue to use the style that prevails in their discipline. --Gerry Ashton (talk) 05:59, 10 February 2009 (UTC)[reply]

To return to the issue at hand, see here (or here). -- Fullstop (talk) 06:16, 10 February 2009 (UTC)[reply]

#time limit?

[edit]

I was updating a couple of heavily used templates to use {{date}} and discovered that there is a limit to the number of times {{#time}} can be called in one page. I'm not sure if this limit is related to the recent server update or an unknown bug the ParserFuction software. --Farix (Talk) 15:40, 18 February 2009 (UTC)[reply]

It seems to be intentional since the error message explicitely refers to #time. Its not specifically related to the sever update of 18 Feb; the error message was seen a few days ago as well. Someone on WP:VP/T might know more.
If the issue is related to repeated object construction (PHP's Date class is quite hacky), then perhaps the devs could mitigate the problem with a one-shot cache (as in: "if input string same as last, then reuse the previously-created class object"). That way one call to {{date}} would correspond to only one "new Date" inside #time.
Perhaps {{date}} could also be rewritten to invoke #time less often. At present, it invokes #time at least 10 times (14 times when the input is a fully qualified date). -- Fullstop (talk) 16:43, 18 February 2009 (UTC)[reply]
Scratch that. It is evidently a template-specific thing. History of Wikipedia has some 200 calls to {{date}} and the resultant 2,758 calls to #time are evidently not a problem.
Since the templates Farix mentions all merely reformat one of their parameters into a human-friendly form, calling '#time:j F Y' directly (instead of via date) solves their problem. -- Fullstop (talk)
The total length of the format strings of the calls of #time is limited to 6000 characters [1].--Patrick (talk) 11:31, 14 September 2010 (UTC)[reply]

Concurrency

[edit]

This template also exists at Commons, but the input requirements are different. I feel they should be the same so users that hop between the projects can use just one format. Please comment at Commons if interested. ~ ωαdεstεr16«talkstalk» 05:02, 6 May 2009 (UTC)[reply]

Non-breaking spaces?

[edit]

How about having the template output include an &nbsp; between day and month, so they aren't split by line breaks?
—WWoods (talk) 14:25, 9 August 2009 (UTC)[reply]

Good idea! -- Fullstop (talk) 17:52, 9 August 2009 (UTC)[reply]
It just struck me that the result of {date} would then no longer be parseable as a date.
{{#time:F&#160;j,&#160;Y}} => ok
but {{#time:j|{{#time:F&#160;j,&#160;Y}}}} => error
There are some templates that manipulate date parameters passed, and they would no longer work if {date} is passed to them. But I have no idea how prevalent such calls are. -- Fullstop (talk) 18:22, 9 August 2009 (UTC)[reply]
I agree that adding unparseable formatting is not a good idea. (also)Happymelon 19:12, 10 August 2009 (UTC)[reply]
Would this also be a problem if the syntax were {{#time:F"&nbsp;"j,"&nbsp;"Y}}? I'm guessing no. I tried it in the sandbox (diff), and it works (checked the test cases as well), but I'm not sure how to test the nesting problem. --Fru1tbat (talk) 13:44, 7 July 2011 (UTC)[reply]
Please, please, please make it have non-breaking spaces! Between day and month, and month (or comma) and year, too! WP:MOS prefers non-breaking spaces anywhere that it makes the prose less hiccuppy (dates splitting across lines, etc.,) ... and as I've recently done hundreds (literally) of insertions of relevant non-breaking spaces into GANs (my mite towards their improvement), it would be soooooooooo nice (not to mention easier for subsequent editors to read, in the edit window) if I could use a nice template complete with non-breaking spaces instead. I will love you forever, if you can just make it insert "&nbsp;" instead of " " Pesky (talkstalk!) 11:58, 26 July 2011 (UTC)[reply]
Seems wrapping the template output into a white-space nowrap span is definitely the way to go.
Please check out the Template:Date/testcases and Template:Date/sandbox pages right now. -- Hnvnc (talk) 11:07, 17 July 2019 (UTC)[reply]

User preferences?

[edit]

I can find no reference on the template page to "user" or "preferences". Does the {{date}} template take into account the preferences of a logged-in user?  HWV258  21:09, 2 December 2009 (UTC)[reply]

No, it does not. MrKIA11 (talk) 21:56, 2 December 2009 (UTC)[reply]
  • It seems that this template does not 'autoformat'. I am at a loss as to the point of using the template. Its use is to dictate a format, but the desired format can be just as easily written out in longhand. So does it still have a raison d'être in this day and age when autoformatting is no longer considered desirable? Ohconfucius ¡digame! 13:47, 13 December 2009 (UTC)[reply]
Yup, what exactly does it do? Is the documentation clear to experienced editors, let alone newbies? I'm confused. Tony (talk) 14:11, 17 December 2009 (UTC)[reply]
I found this template often useful when I came across articles with many ISO dates which I believe to be extremely ugly in prose and references. I found it impossible to convert these ISO dates in large numbers to a human-readable format, but encapsulating them in {{Date}} was within my capabilitities. Such action was never the sole purpose of edits but a by-product of fixing more serious problems. -- Michael Bednarek (talk) 07:12, 18 December 2009 (UTC)[reply]
You can readily convert ISO dates using User:Dinoguy1000/scripts/ISO date format unifier.js. ---— Gadget850 (Ed) talk 12:47, 18 December 2009 (UTC)[reply]
Or use this temaplate like so {{Subst:Date|subst=Subst:|2009-12-29|dmy}} giving 29 December 2009
Rich Farmbrough, 11:15, 30 December 2009 (UTC).[reply]

sortable?

[edit]

Is it possible to modify this template to make it sortable under the table class wikitable sortable? --173.183.102.184 (talk) 10:05, 4 January 2010 (UTC)[reply]

I think the template {{Dts}} is meant for that. -- Michael Bednarek (talk) 13:55, 4 January 2010 (UTC)[reply]

Template:Today has been nominated for merging with Template:Date. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. Set Sail For The Seven Seas 267° 58' 0" NET 17:51, 3 August 2010 (UTC)[reply]

Subst →Safesubst

[edit]

{{editprotected}} Could a templatey administrator change all cases of {{{subst|}}} to {{{|safesubst:}}}? Thanks. Set Sail For The Seven Seas 290° 27' 30" NET 19:21, 4 August 2010 (UTC)[reply]

 Done — Martin (MSGJ · talk) 19:00, 6 August 2010 (UTC)[reply]

BC dates

[edit]

This template does not appear to support BC dates. Because it might be useful, I have implented a BC date template for use with BC dates. But it would be better if you integrated it into this -- then my template would be useless if you did integrate! 'rdococ!' 11:58, 9 July 2011 (UTC) — Preceding unsigned comment added by Rdococ (talkcontribs)

Missing yyyy

[edit]

Your document says: "Recognized values for the second parameter are ... dmy gives d mmmm yyyy (eg 16 July). " The yyyy is missing. yyyy is similarly missing for any other second parameter value listed. It isn't just a document problem, because the template is used to generate the end of that document text, which is encoded as {{date||dmy}}. Therefore, the document is also wrong when it says "If no date is specified, the template emits the current date. For example, {{date}} produces 16 July 2011." You only get the year if the second parameter is also missing. If you specify the second parameter but not the first, the year disappears. Is that what you really wanted the template to do, or is there a software bug in the template itself, in addition to document problems? Art LaPella (talk) 01:35, 16 July 2011 (UTC)[reply]

Funny, I just now noticed the same thing. It looks like the date template was likely recently broken by a change to the template causing this unusual behavior. § Music Sorter § (talk) 03:44, 16 July 2011 (UTC)[reply]
It looks to me like this is the intended template behaviour (and it hasn't been edited since August 2010, so it's not a recent change). The documentation says "If no style is specified, the template emits a date in 'd month yyyy' format" (emphasis added). If you want the year with a style specified, you have to specify the year too. Well, that's my understanding; it's a bit confusing. PS edit protected requests are not for "this template doesn't work", it's for "make specific changes X, Y, Z". For the former, use WP:VPT. Rd232 talk 23:31, 31 July 2011 (UTC)[reply]
  • It wasn't edited since August 2010, but its typical use is in an article with no obvious reason to show the current date, and that is the only function that isn't working.
  • The documentation says "If no style is specified", but reading the rest of the page, "style" refers to the second parameter, so the style was specified and that line doesn't apply.
  • What does apply is what happens in this case, when the style is dmy: "dmy gives d mmmm yyyy (eg 31 July). This is the default format." d mmmm yyyy says you get a year. dmy implies you will get a year. (eg 31 July) says you won't get a year, but that is because "31 July" was generated by the malfunctioning template.
  • But if you really think "dmy" in the second parameter really means "dm", and only when the first parameter is missing, then at least the document should be fixed.
  • The edit protected request wasn't mine. Art LaPella (talk) 00:08, 1 August 2011 (UTC)[reply]

Support for ~~~~~

[edit]

This template does not support the output of ~~~~~ which is 07:09, 10 May 2012 (UTC). I think this should be important to support especially for places were a last updated date may be written as ~~~~~ and then processed by the date template. --ben_b (talk) 07:09, 10 May 2012 (UTC)[reply]

lnone

[edit]

I have added the parameter lnone i.e. link but don't format. To make things easier I also added link which does the same. Thus {{date|xyz|lnone}} & {{date|xyz|link}} are equivalent to [[xyz]] which seems pretty useless, right. So what was the point. It seems likely that a bot is going to go and clean up a lot of the residual mess left over from the bad old days of date linking. Here's a way to link years, decades, centuries, days of the week, etc. without having the bot delink them in the off chance that we'd actually want the link. JIMp talk·cont 09:07, 2 July 2012 (UTC)[reply]

clarification sought

[edit]

It is my understanding that the output of {{date}} pays attention to user preferences, so that those who want dmy get it, and those that want mdy get that. Have I understood correctly? Reading above, it seems not. Apart then from standardising, it all seems a little pointless.

Following on, does the output take any account of user's local language? - January or janvier etc.

Either or both of these would be good for moving on with

John of Cromer in Philippines (talk) mytime= Mon 16:22, wikitime= 08:22, 15 April 2013 (UTC)[reply]

It is my understanding that the template does not observe user preferences. It uses the parser function #time which can emit date/time in different languages, but this template has no provision to accept such a parameter. -- Michael Bednarek (talk) 12:48, 15 April 2013 (UTC)[reply]
Indeed it does not. Which leads to the follow-up question, is there any template that does that? Or i guess a magic word could work... Looks like #dateformat and #formatdate might be the answer, is that correct? -- 188.27.164.206 (talk) 13:15, 21 May 2023 (UTC)[reply]
No idea, but it looks like that would work. I have no interest in customizing dates/times because "13:15, 21 May 2023" is pretty clear to me. If assistance is needed, questions could be asked at WP:VPT but there would need to be an explanation of what was wanted and a reason for wanting it. Johnuniq (talk) 03:25, 22 May 2023 (UTC)[reply]
Fwiw, i was looking for some way to prevent something like this. -- 188.27.164.206 (talk) 22:50, 22 May 2023 (UTC)[reply]
Seeing that (change of date format in an infobox from dmy to mdy) reminds me that developers want the same page delivered to everyone with minimum customization. That allows pages to be cached so the servers do not have to convert wikitext to html every time someone views a page. There is no solution because the next argument is over whether red is a "color" or a "colour". Johnuniq (talk) 00:04, 23 May 2023 (UTC)[reply]

Useless

[edit]

I think I need to say this: without a default that takes into account user preferences for dates, I think this template is largely useless. It defaults to the dmy format. It should default to either the user date preference, or an article-wide preference, or the dmy/mdy format it was given in, or dmy otherwise, in that order.

Is there a way to expose user preferences from templates? Or to combine this with Template:Use mdy dates and friends through some sort of article-wide preference? Maybe using WP:Lua? Int21h (talk) 06:53, 29 May 2013 (UTC)[reply]

I heartily second this request. I think it imperative, and a grave omission, that the template doean't already do this. I'd have thought it a fundamental requirement. As I indicated above, I also think it should take into account user's language preference (which basically is only month name). John of Cromer in transit (talk) mytime= Wed 11:32, wikitime= 10:32, 29 May 2013 (UTC)[reply]

Full date with year in either dmy or mdy format

[edit]

As of 16 September 2013 the template operates such that {{date}} returns the full date (dmy, day month year format), but there is no way to get the full date in mdy, month day year format. Since Wikipedia guidelines stress consistent use of dmy or mdy format within an article, this missing functionality results in unwanted inconsistencies. For example, see the lead paragraph in the Voyager 1 article.

I would like to propose an extension to the {{date}}template, as follows:

  • {{date}} gives the full dmy date, for example: 16 September 2013 - no change in implementation
  • {{date||df=y}} gives the full dmy date, for example: 16 September 2013 - new functionality
  • {{date||mf=y}} gives the full mdy date, for example: September 16, 2013 - new functionality

The use of the "df=y" and "mf=y" is consistent with other date templates (ex: {{birth date and year}}), and allow use of either dmy or mdy format, whichever is appropriate, while maintaining all existing functionality. Truthanado (talk) 23:26, 16 September 2013 (UTC)[reply]

I understand your request is already served by the 2nd parameter if a full date is provided as the 1st parameter: "{{date|{{date}}|mdy}}" produces: "December 2, 2024". -- Michael Bednarek (talk) 12:32, 17 September 2013 (UTC)[reply]

mdy standard

[edit]

Shouldn't mdy be the standard format? That is what is mostly used on Wikipedia I thought. --Jwikiediting (talk) 23:11, 9 October 2013 (UTC)[reply]

There are two standard formats: dmy and mdy. Please see WP:MOSDATE for the details. Tony (talk) 01:56, 10 October 2013 (UTC)[reply]

mdy not working

[edit]

When I type {{date||mdy}}, it's not giving me the year, just the month and day (June 18). It doesn't do it in the documentation either, despite {{date|2006-08-04|mdy}} including the year. When the second parameter is left blank, there is no year produced. You instead have to type {{date|{{date}}|mdy}} to get it to display as documented. This should be corrected to reduce unnecessary clutter in the edit space. BenYes? 18:52, 18 June 2014 (UTC)[reply]

Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. Jackmcbarn (talk) 18:56, 18 June 2014 (UTC)[reply]

Format only input date

[edit]

Is there a way to format dates that are input, without it defaultly providing the current date if none is provided. Alternatively, is there a template that performs such formatting? --Zfish118 (talk) 19:32, 15 July 2014 (UTC)[reply]

What should such a template emit if no input is provided? If the answer is "nothing", the magic word {{#if:…}} can be used. -- Michael Bednarek (talk) 03:37, 16 July 2014 (UTC)[reply]
Currently, this template will return "nothing" if the format is "none", but will return the current date if any format, or the default format is used. If no format is specified, the raw input is returned, which one wonders why the input was placed in the template to begin with. I am looking for a way to clean up raw inputted dates, returning nothing if no date is input. I have tried the #if template, but it seemed to return a blank space, which disrupted the formatting in a web citation template. Using the #if template to turn of the date template if no date were input, it would post "Retrieved ." Perhaps I was missing something. --Zfish118 (talk) 14:47, 16 July 2014 (UTC)[reply]
I seem to have found a work around, if anybody else has this issue:

{{cite web|url=http://example.com | title=example.com | accessdate={{#if:{{{1|}}}|{{date|{{{1}}}}}|}}|}} -- {{{1}}} being a user specified date. --Zfish118 (talk) 15:11, 16 July 2014 (UTC)[reply]

The example does not reliably suppress the date template after testing elsewhere. My original question/request for feature remains. --Zfish118 (talk) 16:12, 21 July 2014 (UTC)[reply]
I resolved the second issue; it was a minor coding error. I still believe that an option to omit the current date if no date were input would result in cleaner template coding. --Zfish118 (talk) 16:17, 21 July 2014 (UTC)[reply]
@Zfish118: You do mean "emit the current date", not "omit", don't you?! --Thnidu (talk) 15:43, 5 July 2015 (UTC)[reply]
In the situation I was describing, I wanted to use the template to format the date passed to it by a parameter, specifically, the "access date" in a citation template. I wanted to use the date template to properly format the display of the access date in the final output. However, if the access date parameter were left blank, the template would instead display today's date, which is incorrect and misleading where the citation is concerned. If the date parameter were empty, I wished the template would return basically nothing (ie, omit the current date). --Zfish118 (talk) 17:19, 5 July 2015 (UTC)[reply]

"No date specified" examples are wrong

[edit]

Since it is now 15:53, 5 July 2015 (UTC), the following is obviously untrue:

If no date is specified, the template emits the current date.
For example, {{date}} produces 27 June 2015.

But if I actually enter {{date}}, I get the correct result, currently 5 July 2015.

As live evidence, this paragraph ends with a live invocation of {{date}}, which should be accurate whenever you read this: 2 December 2024

So these examples are confusing, to say the least. What's going on? Please {{Ping}} me to discuss.

--Thnidu (talk) 15:54, 5 July 2015 (UTC)[reply]

As of July 5, 2015, the Date template seems to be returning the correct current date when none is provided. @Thnidu: --Zfish118 (talk) 17:32, 5 July 2015 (UTC)[reply]
@Zfish118: Yes, I know that. That wasn't my point; see the title of this section. The examples in the documentation are wrong. Instead of showing the current date, they are* were showing "27 June 2015", which I suppose is the date that they were edited in* the page was last edited.
*Since I made a null edit to the page (inserting and deleting a space), they are correct... and will remain so for about 23 hours, since they now show today's date, 6 July 2015, in various formats. What needs to be done to make them yield the correct date every time the page is displayed? Please {{Ping}} me. --Thnidu (talk) 01:18, 6 July 2015 (UTC)[reply]
Hmmm, I see you point. Your "Live" evocation seems stuck at July 6. Today, on July 11, I am placing a date template here: "2 December 2024"; to see if I get the same results. --Zfish118 (talk) 21:14, 11 July 2015 (UTC)[reply]
Having made the above edit, both templates now display July 11. It seems that each time the page is edited, Wikipedia has to redrender the page and all the templates, and then caches this version until the next edit so that a static version can be downloaded to save time. @Thnidu: Based on what I am observing, I am uncertain if what you are asking is possible, at least not with a traditional template. To display the current date, you would need some form of active code, possibly JavaScript or Wikimedia's built in "WP:Lua" scripting. The code would need to pull the current date every time the page loads, rather than relying on the cached static copy of the current version stored on the Wikipedia server. --Zfish118 (talk) 21:33, 11 July 2015 (UTC)[reply]

mdy format not working when substituted

[edit]

I'm doing a search and replace to remove inappropriate uses of {{Start date}} for alternative dates in episode lists. {{Date|2015-7-13|mdy}} gives "July 13, 2015" as expected, but substituting it results in "13 July 2015". nyuszika7h (talk) 14:58, 11 September 2015 (UTC)[reply]

This appears to be due to the usages of the {{lc:}} magic word not being substituted. I've edited the sandbox version to fix that; substituting it gives {{subst:Date/sandbox|2015-7-13|mdy}} → "July 13, 2015". Unfortunately the template is fully protected rather than template-protected, so an admin will be needed to either make the change to the real template or reduce the protection level. SiBr4 (talk) 16:47, 11 September 2015 (UTC)[reply]
See also the testcases. SiBr4 (talk) 17:04, 11 September 2015 (UTC)[reply]
@Nyuszika7H: Fixed now (thanks NeilN for downgrading the protection). SiBr4 (talk) 16:07, 12 September 2015 (UTC)[reply]

Microformats

[edit]

Should we use the date microformat for dates to allow parsers to get the semantics that it is a date? --MartinThoma (talk) 19:54, 22 March 2016 (UTC)[reply]

Shouldn't use {date} in articles. Easy cleanup using safesubst:

[edit]

"This template should only be used internally in other templates." (It doesn't say why, but I'm okay with it.)

Despite this, {{date}} is used many times in many articles.

The easy way to clean up the mess should be substitution, which would replace each template invocation ({{date|2015-02-13|mdy}}) with its expansion (February 13, 2015) in the markup, upon saving.

Mass-replacing '''{{date''' with '''{{subst:date''' does not work inside <ref> tags. (A bug reported since 2005.)

Mass-replacing '''{{date''' with '''{{[[Help:Substitution#The safesubst: modifier|safesubst]]:date''' works inside <ref> tags. -A876 (talk) 07:51, 10 February 2018 (UTC)[reply]


It's used in the oldest people articles, it uses age as of 2 December 2024


{{date}} - 2 December 2024

Date Input

[edit]

I was seeing if all numeric can work, when I use DD/MM/YYYY, MM-DD-YYYY, MM.DD.YYYY, MM.DD.YY, MM-DD-YY, YY/MM/DD, YY.MM.DD, YYYY.MM.DD are all invalid, formats MM/DD/YYYY, DD-MM-YYYY, DD.MM.YYYY, YYYY-MM-DD, YYYY/MM/DD are all valid

input {{date}}
{{date|05/31/2012}} 31 May 2012
{{date|05-31-2012}} 05-31-2012 gives me an error

I normally use {{date|05/31/2012}} which doesn't give me any errors, I use slashes indicate MM/DD/YYYY and hyphens DD-MM-YYYY — Preceding unsigned comment added by 98.31.29.4 (talkcontribs) 00:21, 24 July 2018 (UTC)[reply]

This template uses fragile code to interpret the date. Please stick to the examples in the documentation. In particular, do not use 05/31/2012 (which might have been 05/09/2012) because it is incredibly ambiguous even if the template currently does what you intended. Johnuniq (talk) 02:38, 24 July 2018 (UTC)[reply]

{{date|05/31/2012}} displays 31 May 2012

Why is YMD not a valid input

[edit]

{{Date|2008 December 1|MDY}} gives 2008 December 1 expected December 1, 2008, so what's the point?— Preceding unsigned comment added by 2605:a000:1103:220f:cda:5ac6:a081:c425 (talkcontribs) 18:11, 25 July 2018 UTC (UTC)

The result of instantiating {{Date|2008 December 1|MDY}} is 2008 December 1. The documentation states "input strings that the template cannot format are returned unaltered." Since the output not in the MDY format, we can infer that the template could not parse the input string and returned it unaltered. Jc3s5h (talk) 16:37, 7 September 2018 (UTC)[reply]


Here's a way around this


{{date|{{YMD to ISO|2011 August 16}}|DMY}} gives 16 August 2011
{{date|{{YMD to ISO|2011 August 16}}|MDY}} gives August 16, 2011
{{date|{{YMD to ISO|2011 August 16}}|ISO}} gives 2011-08-16

Date formatting

[edit]

{{date|05/31/2012}} gives 31 May 2012
{{date|5/31/2012}} gives 31 May 2012
{{date|05/31/12}} gives 31 May 2012
{{date|5/31/12}} gives 31 May 2012

— Preceding unsigned comment added by 2605:a000:1103:220f:b16b:1989:746e:84ab (talkcontribs) 00:54, 28 July 2018 (UTC)[reply]

ISO date without year

[edit]

So for an example {{date|06/04/2016|ISO}} gives me 2016-06-04 which works perfectly
{{date|Jun 4|ISO}} gives me June 4 gives me the same format as {{date|Jun 4|MDY}} and {{date|Jun 4|YMD}}

So help me is there anyway to display September 2 as --09-02 for the ISO format? — Preceding unsigned comment added by 2605:a000:1103:c3:399a:138a:ed29:909c (talkcontribs) 21:23, 2 September 2018 (UTC)[reply]

Yes, just write 09-02 or whatever you want. However, that is very unlikely to be desirable. Johnuniq (talk) 23:25, 2 September 2018 (UTC)[reply]


Here's what can solve the problem

12-02, displays the current date
09-02

Date with year: 2024-12-02
Date without year: 12-02 — Preceding unsigned comment added by 2600:1:b1a6:97c5:b53a:2108:a250:3651 (talkcontribs) 12:56, 24 September 2018 (UTC)[reply]

{{date||ISO}} will input the format as Month DD, why?

The current 2004 version of ISO 8601 does not provide for omitting the year from a date. The strings given above, "--09-02" and "09-02" are wrong. That last string was produced by User:2605:a000:1103:c3:3428:23cc:b7ce:3c3d with this wikitext '''{{date|09-02|ISO}}'''. Keep in mind that when the template can't parse an input, it just returns whatever was input, so there's no telling if that's intended to be a valid result without going into the template code and tracing through it. Jc3s5h (talk) 20:57, 15 October 2018 (UTC)[reply]

Yes, the current 2004 version of ISO 8601 does not permit omitting the year from a date, but this template will supposedly produce an ISO output when the year is missing. — Preceding unsigned comment added by 2600:1:91B0:EF43:2177:756:393F:B479 (talk) 19:06, 7 December 2018 (UTC)[reply]

dd/mm/yyyy or mm/dd/yyyy

[edit]

I tried displaying {{date|31/05/2012}} to be 31/05/2012 gives an error but {{date|05/31/2012}} gives 31 May 2012

When slashes are interpreted they are in mm/dd/yyyy — Preceding unsigned comment added by 2600:1:b1a6:97c5:b53a:2108:a250:3651 (talkcontribs) 12:56, 24 September 2018 (UTC)[reply]

As explained above, please stop using ambiguous date formats that are not documented. Johnuniq (talk) 23:53, 24 September 2018 (UTC)[reply]

Only use in other templates?

[edit]

The docs say "This template should only be used internally in other templates." Does anyone know why templates would have this embedded template, and not use a plain-text date? -- GreenC 18:31, 3 January 2019 (UTC)[reply]

Here is a link to all pages in Template space that transclude this template. Many instances appear to be transclusions in template documentation to show a relatively current date. Of the roughly 300 pages that are actual templates, I clicked through to a dozen or so and found only one instance of the date template being used usefully in an actual template, in Template:Being deleted. – Jonesey95 (talk) 21:38, 3 January 2019 (UTC)[reply]
Oh, "only meant internally" means only for use in Template namespace? Wow. -- GreenC 22:26, 3 January 2019 (UTC)[reply]
It looks like that warning was added to the documentation in April 2014, more than six years after the documentation was created.
In 2009, the documentation said: This template is probably best used as a way of standardizing the appearance of all dates in an article, including those in citation templates and infoboxes.
In December 2009, those instructions were changed to: This template is probably best used internally in other templates.
It looks that recommendation was changed in April 2014: This template should only be used internally in other templates.
I am unable to find any discussion on this template's talk page supporting any of the above edits. My interpretation of the above changes is that using this template within template invocations in any namespace is supported by the documentation. I don't know why there would be a problem with putting something like {date|December 3, 2009|DMY} within article prose, although it seems like overkill that should be substed. I might compare it to {{convert}}, which allows for minimal or slightly inconsistent input while producing consistent output. – Jonesey95 (talk) 00:49, 4 January 2019 (UTC)[reply]
I have been watching this page for a while due to my interest in Module:Date and related stuff. I never got around to working out what this template is for, but my assumption was that some other template, say Template:Example, would have a parameter, say 'date', and that template could be called with '|date=2016-04-30' and Template:Example might want to display that in DMY format. It could use this template to do that. Johnuniq (talk) 01:09, 4 January 2019 (UTC)[reply]

Incorrect behavior for edge case with ISO format

[edit]

According to the documentation, {{date|Aug 4|ISO}} should output --08-04; instead, it outputs August 4, which isn't even a valid ISO string. Conscious Code (talk) 21:02, 19 January 2019 (UTC)[reply]

When no date is specified

[edit]

Well on Google Sheets if no date is specified is the number 0 which is 30 December 1899, but on this if no date has been specified it will display today's date.--2605:A000:1103:45:BC1C:3F06:D44C:C550 (talk) 18:56, 9 February 2019 (UTC)[reply]

Abbreviated month name format?

[edit]

How can we force the date output have an abbreviated month (e.g. 15 Mar 2019) like what {{MONTHABBREV}} does? There should be an optional parameter like disp=abbr.–Sanglahi86 (talk) 18:21, 14 March 2019 (UTC)[reply]

Sanglahi86, I don't think this template supports that output format, but the #time: parserfunction does. so, for example, {{#time:j M Y|March 15, 2019}} reformats a date to that format, or {{#time:j M Y}} shows the current date in that format. Frietjes (talk) 16:52, 18 March 2019 (UTC)[reply]
Thank you very much for the information. –Sanglahi86 (talk) 16:58, 18 March 2019 (UTC)[reply]

Typo in "Known issues" documentation

[edit]

For the phrase "ISO 8601 does not permit omitting from the year", is there agreement that the extraneous "from" can be removed? Martin Kealey (talk) 03:59, 7 April 2019 (UTC)[reply]

Good catch. Fixed. – Jonesey95 (talk) 05:48, 7 April 2019 (UTC)[reply]

Adding dates

[edit]

Is there a template which can be used to automatically add dates and find the combined age?

The specific use case I'm looking at is: in the US political system, judges are eligible for a kind of semi-retirement called 'senior status' once their age > 65 and their age + their number of years as a judge = 80. (So, an 80-year old judge would always be eligible for senior status, a 70-year old judge would only be eligible if he'd served as a judge for at least 10 years, a 65-year old judge would only be eligible if he'd served as a judge for at least 15 years, and a 60-year old judge would not be eligible). I'm experimenting (right now just on my sandbox page) with adding a 'Senior Status eligible?' column to the lists of judges on the various courts pages, but keeping that maintained manually on the hundred+ court pages wouldn't be tractable.

What I'm hoping is for there to be a template where I could put in multiple dates and have Wikipedia calculate their combined age. So if one judge was born exactly 65 years ago, and that judge started judicial service exactly 10 years ago, I could enter both those dates into the template and have the template say something like 'combined age 75 years', which I could then use to sort the judges and indicate those who are eligible for senior status.

Does a template like that exist?

Thanks! AaronCanton (talk) 02:03, 21 November 2019 (UTC)[reply]

I don't know of such a template. You might ask at WP:VPT. If you provide example syntax and a link to an article where it would be used, someone might make a template. Johnuniq (talk) 02:50, 21 November 2019 (UTC)[reply]
Based on the rather vague spec above, I have created Template:Senior status. Please try it and let me know if it works. If it does, I need to add proper documentation and do some testing. – Jonesey95 (talk) 04:44, 21 November 2019 (UTC)[reply]
One note: With minor changes to Template:U.S. judgeship row Current, we could probably do all of these calculations within that template. Where is a good place to discuss that option? – Jonesey95 (talk) 05:06, 21 November 2019 (UTC)[reply]
I like the idea of including the Senior Status part within the template, so it can be smoothly included as another column in the table. That said, we'll need to be careful and make sure the template is set up to accept the user manually entering the appointment date instead of just reading it from the 'Term of Service: active' column, because sometimes the Senior Status calculation involves years of service from multiple judgeships. For example, suppose a judge is appointed to the Southern District of New York on his 50th birthday, then promoted to the 2nd Circuit Court of Appeals on his 60th birthday. On his 65th birthday, he would be eligible to take senior status (age > 65 years, age + total years of service > 80), but the judge's template on the '2nd Circuit' page would show he was just appointed to that specific court 5 years ago, and wouldn't include the judge having already served 10 years in a lower article III court and would have to enter that manually.AaronCanton (talk) 22:11, 23 November 2019 (UTC)[reply]
Thanks! I'll test this.AaronCanton (talk) 22:12, 23 November 2019 (UTC)[reply]

I'm concerned about the use of calculating something like senior status, rather than updating it manually. It's entirely possible that a judge dies before reaching senior status. It's also entirely possible that the Wikipedia article about the judge will not be updated to reflect the death. If a calculation is done, Wikipedia will appear to affirmatively state that the judge reached senior status when (s)he never did. Jc3s5h (talk) 17:31, 25 November 2019 (UTC)[reply]

I believe that this template and calculation were intended only for use in lists of sitting judges. That would be yet another reason to integrate the calculation into Template:U.S. judgeship row Current, as suggested above. Perhaps AaronCanton could respond. – Jonesey95 (talk) 19:30, 25 November 2019 (UTC)[reply]
Yes, I was only thinking of using this for lists of sitting judges--such as in the articles on the various US federal courts. If a judge dies, then the judge is removed from the relevant lists. AaronCanton (talk) 01:40, 26 November 2019 (UTC)[reply]

Can I make it omit part of the input?

[edit]

For example, if it is nested in a template that feeds it 2021-02-03, can I tell it to ignore the year and give me February 3 as an output? —Arctic Gnome (talkcontribs) 01:31, 21 January 2021 (UTC)[reply]

That could be done with #time ([2]) or {{extract}}.
  • {{extract|3 Feb 2021|show=%{monthname} %{day} }} → February 3
  • {{extract|2021-2-3|show=%{monthname} %{day} }} → February 3
The more obscure codes shown at Module:Date can also be used.
  • {{extract|2021-2-3|show=%B %-d}} → February 3
Johnuniq (talk) 01:44, 21 January 2021 (UTC)[reply]

Second default not meaningful under VisualEditor conditions

[edit]

Documentation tells that there shall be a significant difference in presentation of

  • {{date}}
  • {{date|}}

Please note:

  • VisualEditor users have no capability to distinguish between two types of empty fields.
  • The parameter 1 has suggested state in VisualEditor. That does mean that an empty field will be created always if this template is touched by VE.

Greetings --PerfektesChaos (talk) 15:12, 19 March 2021 (UTC)[reply]

File a Phabricator bug? In the first instance, |1= does not exist. In the second instance, |1= exists but is empty. – Jonesey95 (talk) 18:37, 27 June 2021 (UTC)[reply]
This is not a Phabricator bug.
The MediaWiki behaviour has been created in 2004 with introduction of template parameters and must not be changed.
VisualEditor has no other way to act as implemented.
It is a problem of this template programming, and the expectations.
It is made worse since TemplateData is specifying suggested state for this template. This forces inserting of an empty parameter assignment in general without any further user activity.
It is almost impossible for authors within VisualEditor form to distinguish the meaning of an empty or a missing field.
It is also hard to understand for source code editors that an empty parameter assignment has a different meaning than not occurring parameter. An innocent additional pipe before an option parameter will cause the same effect.
Best, --PerfektesChaos (talk) 22:49, 10 July 2021 (UTC)[reply]

Can we make the date format fields in templates a bit more intelligent?

[edit]

This is not directed just towards this template, but to all templates that have a date field. Take the following six examples:

  • "Test". 2022-04-05.
  • "Test". 2022-April-05. {{cite news}}: Check date values in: |date= (help)
  • "Test". Apr 5, 2022.
  • "Test". April 05, 2022. {{cite news}}: Check date values in: |date= (help)
  • "Test". APRIL 5, 2022. {{cite news}}: Check date values in: |date= (help)
  • "Test". Apr. 5, 2022. {{cite news}}: Check date values in: |date= (help)

Of these, only the first and third parse, even though it is immediately clear to the reader what dates are intended by the rest. This becomes a problem where dates formatted with these variations are copied from a source website. Putting aside MOS issues, can't we make templates recognize that 05 in any "day" parameter means 5, and that in the month parameter, April = Apr. = Apr = APR = APRIL? We can always have a bot come through and conform them to the preferred style later on. BD2412 T 05:12, 27 April 2022 (UTC)[reply]

I would add, by the way, that this should apply to different month shortenings, as with:

The templates just conform to MOS. If you want Wikipedia to allow different formats, suggest a change at WT:MOSDATE. It has happened in the past. The above tolerance seems like a slippery slope to me. Should we allow "Ap" for "April"? What then with "Ju" or "Ma"? Should 2022-13-05 or 05-13-2022 be allowed? Like "Ap", they are unambiguous but lead to trouble. Where does the madness end? Right now it ends at MOS:DATESNO, which begins with the word "Unacceptable". – Jonesey95 (talk) 06:22, 27 April 2022 (UTC)[reply]
I'm not looking to change the MOS, just the software. Recognizing dates in a template does not mean allowing those as a style matter. With respect to "Ap" for April, I would say that the program parsing the template should recognize variations that are commonly used by people in the real world, particularly on sites that may be used as references in articles. I don't think I have ever seen anyone use "Ap" for "April", but we have all certainly seen "Apr." and "APR" and "APRIL", and likely "Sept" as often or more often than "Sep", and "Decem." often enough. I would also note that just because a template throws up an error message, that doesn't mean that anyone ever bothers to fix it, or even that a novice editor would be able to figure out how to fix it. They might try several variations that are commonly in use (but not recognized) and give up. We have plenty of very old error messages in articles throughout Wikipedia. BD2412 T 06:30, 27 April 2022 (UTC)[reply]
I would prefer restricting what is accepted for better consistency in what people see while editing. That is, "Dec" and "December" are fine, but I don't see why all possible abbreviations (and "obvious" typos?) should work. However, I don't feel strongly about that. An easy fix would be to use the #time functions but they have the fatal flaw of accepting myd numbers like 4/1/22 for April 1, 2022. That cannot be allowed because it would hide blatant errors where an editor intended 4 January 2022. By the way, this template is not used by {{cite news}} used above. Johnuniq (talk) 06:53, 27 April 2022 (UTC)[reply]
No one has proposed to allow the recognition of typos. As for the transposition of dates in mdy verses dmy systems, that can already happen where numers are already allowed. I don't see how allowing, e.g., April 01, 2022, or Apr. 1, 2022, would cause mischief there. BD2412 T 17:37, 27 April 2022 (UTC)[reply]
The general-purpose software that is available to parse dates tends to have many restrictions that tend to confuse editors. Using the citation templates as an example, the software chosen to implement it is unable to deal with some legitimate dates; see Help:Citation Style 1#Date format compliance with Wikipedia's Manual of Style. I suspect that choosing a software package that can accept a wider range of abbreviations and typographic variations will also increase the number of legitimate dates that cannot be used. If, for example, an important date could not be rendered in an infobox because of the date parsing software used by the infobox, it might be necessary to remove the infobox from the article entirely. Jc3s5h (talk) 12:29, 27 April 2022 (UTC)[reply]
  • IMO complexity equals problems. And Wikipedia has become ever so complex. It's not just CS1|2 that has to parse, but every bot or future bot that is required to maintain Wikipedia. Every bot coder using whatever tools or language they have, must then be required to handle date strings. Or web tools same thing. Or when exporting data and parsing into databases for academic research, or other projects. There is a huge ecosystem of people using this dataset beyond the immediate. The more complex, the more problems, the less accessible. I think a range of possibilities and the rest get error messages is best. -- GreenC 13:53, 27 April 2022 (UTC)[reply]
    • If we are going to have error messages for correct (in the real world) formulations of dates, then we should at least have a bot that cleans these up, rather than letting them sit for years. BD2412 T 17:39, 27 April 2022 (UTC)[reply]
      Absolutely. A date-bot that does date normalizations is a great idea for WP:BOTREQ. It could run indefinitely cleaning up errors. That way only one person has to be expert on the many date variations, instead of everyone. -- GreenC 19:10, 27 April 2022 (UTC)[reply]
      User:BattyBot's task 25 has been fixing date errors in citation templates since 2013. If you see examples of dates that it could fix but which it currently does not fix, please drop a note with its operator. The bot's edits, along with diligent gnome edits, are the reason that Category:CS1 errors: dates has only 6,500 pages in it, down from something like 150,000 just a few years ago. And I believe that you will find, if you do a random sample, that the vast majority of those errors are not bot-fixable. I just did a semi-random sample of five articles and found zero bot-fixable dates. – Jonesey95 (talk) 20:51, 27 April 2022 (UTC)[reply]
      I have fixed fixable bad dates in templates, but perhaps they were recently left when I found them. Probably from my watchlist. I wasn't aware of the bot handling this. BD2412 T 22:07, 27 April 2022 (UTC)[reply]
  • If wanted, work could be done on Module:Date to provide a uniform way to handle dates. I hesitate to suggest that because the code is tricky and it would be easy to make it break with untested corner cases. Its problem is that it cannot realistically be internationalized for use on other projects. Some thought might make the interfaces (what it exports) able to be replaced with calls to mw.language:formatDate. I didn't use formatDate because, as I recall, it behaves like #time and accepts ambiguous dates such as 1/4/22 which would cause chaos here. An example showing which of the above dates are currently accepted is at sandbox2 (permalink). Johnuniq (talk) 02:34, 28 April 2022 (UTC)[reply]

YDM format (year-day-month) format

[edit]

{{date|1948 18 January|MDY}} outputs as January 18 without the year instead of January 18, 1948

Even with YDM parameter isn't recognized, for an example {{date|January 18, 1948|YDM}} outputs as 18 January 1948 (expected 1948 18 January) as if it we're to be treated as DMY format


So using {{FULLDATE}} template, {{FULLDATE|type=mdy|time=1948 18 January}} outputs as January 18, 2024 as the current year (expected January 18, 1948)


How is YDM parameter not an option?, it's treated like if it were to be DMY

--98.31.29.4 (talk) 21:31, 3 June 2022 (UTC)[reply]

Any YDM input or output would need to be examined so any format like where {{date|2=YDM}} outputs as 2024 2 December
So {{date|January 18, 1948|YDM}} outputs as 1948 18 January
Even inputs like {{date|1948 18 January}} outputs as 18 January with the year missing even when using
{{FULLDATE|type=dmy|time=1948 18 January}} outputs as 18 January 2024 with the {{Currentyear}} instead of 1948, so YDM doesn't return unalternated as an input like how YMD does but it does not provide the year though. 2603:6011:E00:4C41:0:0:0:100F (talk) 02:54, 18 March 2024 (UTC)[reply]

Abbreviated month

[edit]

Could we please allow an option of showing abbreviated months, like Sept. 9, 2022? This would be useful in tables and infoboxes where space is limited. —Arctic Gnome (talkcontribs) 15:08, 9 September 2022 (UTC)[reply]

"Sept." is not a valid month name format per MOS:DATESNO. "Sep 9, 2022" would be valid, though. I don't see a way to generate that format using this template, however. – Jonesey95 (talk) 18:23, 9 September 2022 (UTC)[reply]
I only have a rough understanding of how this is coded, but I see a #switch function with the line |mdy = F j, Y. Could that be followed by a line reading |mdy-short = M j, Y? —Arctic Gnome (talkcontribs) 19:29, 9 September 2022 (UTC)[reply]

Automatic age

[edit]

I would like to know how to automatically age a date and age template in Portuguese, case in point:Predefinição:Presidente da República Portuguesa por idade, I've tried several and failed, this type of parameter works in English templates (example:Template:United States presidents by age).

Best – Ser.Silv. (talk) 09:35, 26 October 2022 (UTC)[reply]

Make the date template emit time metadata, ensuring accessibility and allowing people to view dates in their preferred format.

[edit]

The data template needs to emit the invisible <time></time> HTML block around the generated date, which is used to communicate the date to accessibility software like screen readers or software for the visually impaired.

Chrome-based web browsers have the ability to localize the date in time blocks to the user's specified language or display preference. Users of these browsers can set their date display preference in the browser's language settings.

Additionally, The time block would allow search engines to parse dates with better precision, allowing them to better suggest Wikipedia articles. — Preceding unsigned comment added by MatthewUtzig (talkcontribs) 23:12, 7 April 2023 (UTC)[reply]

100% agreed. I've actually been inserting {{date}} lately because I just assumed it would add structured data. To find that it doesn't is disappointing. Since time is an allowed HTML tag in MediaWiki, there is no reason to not include it. ―Justin (koavf)TCM 13:17, 8 April 2023 (UTC)[reply]
According to this Mozilla web page the value represented within the tag MUST be in the Gregorian Calendar. The documentation for this template mentions some limitations when trying to work with Julian calendar, there is no prohibition against using Julian calendar dates with the Date template. Since this template has been widely used without notifying users they must only use Gregorian dates, it's to late to change now. Jc3s5h (talk) 23:52, 8 April 2023 (UTC)[reply]
Agreed. Adding the the metadata to the Date template is impossible. And even if we could, we couldn't go around adding it to every date on Wikipedia without creating a major performance issue.
Therefore, I am creating a new project at Wikipedia:WikiProject Accessibility/Datetime Metadata, with the goal of creating new performance-oriented templates for this purpose. MatthewUtzig (talk) 04:38, 9 April 2023 (UTC)[reply]
Many uses of this template within templates depend on raw text output of the date. See just one example at {{Being deleted}}. Creating a separate template that wraps dates in metadata may be the best option. – Jonesey95 (talk) 06:52, 9 April 2023 (UTC)[reply]

How to avoid the default change?

[edit]

Is there a way with this template (or a similar template) to avoid the default shift to dmy format? But still have the date change if Template:Use dmy dates is used on the page? Rjjiii (talk) 13:53, 28 October 2023 (UTC)[reply]

Default comment-time format

[edit]

Is there a template/parameter for this template that matches the format of times used to sign comments (such as at the end of this one)? Tule-hog (talk) 23:39, 29 July 2024 (UTC)[reply]

It is five tildes (~~~~~), as mentioned here. Tule-hog (talk) 23:45, 29 July 2024 (UTC)[reply]
It's a bit of a mess but the following example using {{extract}} uses the format codes documented at Module:Date#Formatted output.
  • {{extract|2024-07-29 23:45|show=%H:%M, %-d %B %-Y (UTC)}} → 23:45, 29 July 2024 (UTC)
Johnuniq (talk) 01:25, 30 July 2024 (UTC)[reply]
My interest was more for the grayed-out style than the (UTC) - 5-tildes doesn't satisfy it either, so this is neat too! Tule-hog (talk) 01:29, 30 July 2024 (UTC)[reply]
Sorry, I thought I was at Module talk:Date where the above answer might make sense. Ask at WP:VPT to find how to get the color. Johnuniq (talk) 01:37, 30 July 2024 (UTC)[reply]