Module talk:Complex date

Planned usage

• Preserve legacy output from original template
• {{other date|mod1=early|date1=20|junction=-|mod2=mid|date2=21|precision=century}} outputs from early 20th century until mid 21st century
• {{other date|mod1=early|date1=2014|junction=-|mod2=mid|date2=2100|precision=year}} outputs from early 2014 until mid 2100

Sn1per (talk) 17:26, 20 December 2014 (UTC)

Hopeless

I don't even see the place where I could add or fix the reported bug for ?, i.e., either track an error for ? with one or two dates, or handle the latter as shorthand for between, while ? with one date could be an error for a wide safety margin between unknown (no date) and between (two dates). ? with one date could be also handled as "far more unclear than" ~, translated as guess, unclear or similar, while ~ is in essence {{circa|…}}.

The location where the translations are stored is unidentifiable. For any given language contributors MUST be able to translate "after", "before", "between", etc. in less than the proverbial five minutes, including reading all manuals, and running an existing test suite to check the effect of a planned modification (BiDi).

Obvious errors, e.g., < with no or two dates, need an error tracking category, and a very visible error output, it can also blink and create noises as far as I'm concerned. {{other date|<|2006|1999}} yielding before 2006

date QS:P,+2006-00-00T00:00:00Z/7,P1326,+2006-00-00T00:00:00Z/9

is not good enough, it's actually an attack vector for subtle vandalism or pointy spam. –Be..anyone (talk) 22:04, 14 February 2015 (UTC)

I had to reread this several times to figure out what reported bug are you referring to, but I guess you would like to have a maintenance category tracking more cases of the template use where some of the parameters are not used. In 6 years since User:Slomox wrote the initial version of this template we never tracked such files, and I have never seen files with extra or unused parameters. But since lately we started tracking similar problems for {{Information}} and many other templates with categories like Category:Pages using Information template with incorrect parameter we could start tracking it for {{Other date}} and {{Complex date}}. We already have Category:Pages using Complex date template with incorrect parameter used for unrecognized parameters ({{Other date|foo|2000|2001}}), but we could use it for that case too. Some issues would be easier to handle than others:

• issue like {{Other date|-|2000|2001|foo=...}} can be handled with Module:TemplatePar (check function) , also used by {{Information}} and many other templates
• but extra date in {{other date|<|2006|1999}} would have to ba handled in Module:Complex date. I will think on how to best add it. --Jarekt (talk) 05:16, 17 February 2015 (UTC)

typography

I really have now clue about what exactly (or whether it's even this module) should be changed here, but currently, only the typographically incorrect "-" is accepted as a from-until parameter alias, while the correct punctuation mark, "–", isn't.    FDMS  4    14:02, 24 February 2015 (UTC)

I think I fixed it. It is hard to tell since in many fonts there is no difference between both versions. --Jarekt (talk) 14:35, 24 February 2015 (UTC)

Thank you, works fine.    FDMS  4    15:00, 24 February 2015 (UTC)

Broken with "other date" on specific locales

Broken on when Persian locale is set and other date is used, 1, any idea? (cc: User:Jarekt). −ebraminio^talk 19:39, 10 July 2015 (UTC)

I will look into it. --Jarekt (talk) 20:02, 10 July 2015 (UTC)

@Jarekt: The problem is that the _main() function no longer exists in Module:Formatnum so formatnum in "local formatnum = require('Module:Formatnum ')._main" is nil. —RP88 (talk) 21:06, 10 July 2015 (UTC)

User:RP88, User:Jarekt: fixed. Thanks to both of you −ebraminio^talk 21:29, 10 July 2015 (UTC)

Actually not. Now I found that why _main was used at the first hand, it seems formatNum doesn't support string. What should be done for it? (1, cc: User:Verdy p) −ebraminio^talk 21:36, 10 July 2015 (UTC)

Hmm, it supports string but not when it is concatenated with other string. Not sure why oneDatePhrase calling "1st century" on formatnum1 −ebraminio^talk 21:58, 10 July 2015 (UTC)

RP88 and ebraminio thanks for figuring it out. It is a good catch and I would not have suspected that Module:Formatnum would get rewritten without providing backward compatibility or checking what uses the module. It is working now, although it is not working as I intended. I was trying to use formatnum1 to convert 1 to Arabic numeral, but I guess it does not happen since string has number and letter mix. --Jarekt (talk) 13:30, 13 July 2015 (UTC)

Date formatting at round years is inconsistent with that of wikidata

Please, take a look at discussion about century and millennium definition. It looks that 2000 year in wikidata is 20th century and 2nd millennium (proof). At the same time Module:Complex date treats 2000 as 21st century (proof: 21^st century

date QS:P,+2050-00-00T00:00:00Z/7

– this text was generated by this module) and 3rd millennium (proof: 3^rd millennium

date QS:P,+2500-00-00T00:00:00Z/6

). -- VorontsovIE (talk) 16:18, 7 April 2018 (UTC)

VorontsovIE, the problem is that the template originally to get 20th century you needed to use {{Other date|century|20}}, latter someone lobbied to allow the first year of the century or millennium to encode it, the way we allow {{Other date|s|1970}} to specify 1970s. The same way 1900s with "century" precision would give you 20th century, or 2000s with "millennium" precision would give you 2nd millennium. Somehow before Wikidata nobody realized that first year of millennium was 2001, I guess everybody was so preoccupied with Y2K bug to notice. If we change it now than great many pages would and up with incorrect date displayed. We could only fix it is me would change all the pages that currently use that option. --Jarekt (talk) 18:11, 8 April 2018 (UTC)

Returned string

You might expect that

• {{#invoke:Complex_date |complex_date |date1=1951}} → 1951

would return 1951, but it doesn't. It returns <span style="white-space:nowrap"><time class="dtstart" datetime="1951">1951</time></span>, which is going to screw up any use of the date within a compound item. Trying to use it to construct categories like this:

• [[:Category:{{#invoke:Complex_date |complex_date |date1=1951}} births]] → [[:Category:1951 births]]

fails to construct a category link because of the extra ‎<span>...‎</span> and ‎<time>...‎</time> tags.

The module would benefit from a switch that turned off the extra wrapping (perhaps use :gsub("<[^>]*>", "") ), plus some documentation of what is returned. Cheers --RexxS (talk) 19:51, 8 September 2018 (UTC)

I do not remember why all that html was added or if it is actually needed we definitely do not need it for {{#invoke:Complex_date |complex_date |date1=1951}}. I will look through the code to remind myself why we have it. --Jarekt (talk) 01:26, 9 September 2018 (UTC)

@RexxS and Mike Peel: all that marking does not come from Module:Complex_date, but from Module:Date. I guess what happen is that both of those modules are designed for internationalization of dates and date related phrases, so output of those modules were never meant to go into category names, etc. So the call to {{date|1951}} will have the same marking. The marking was added in 2009 by @Pigsonthewing: with this edit. We can check with Andy if he, or others are still using it. --Jarekt (talk) 03:29, 9 September 2018 (UTC)

@Jarekt: I've changed Module:WikidataIB to use this module in order to internationalise dates, and Mike will want to use it to add categories automatically when a date-of-birth or similar is available on Wikidata. If you're interested, the code is (currently) in lines 662 to 711 and I was able to strip the tags in line 700, so that application is working now. I was just thinking that you might want to introduce a boolean parameter something like |plain= that switches the stripping of any tags from the output of function p._complex_date if anybody else might find it useful. Cheers --RexxS (talk) 16:38, 9 September 2018 (UTC)

Thanks, I was just trying to remember where this marking comes from and why do we need it. --Jarekt (talk) 19:16, 9 September 2018 (UTC)

It's just adding a microformat on the assumption that dates should emit them where possible, which is usually fine, but Mike managed to find an example of where it isn't. Of course, once I strip out the tags, I also remove the <div style="display: none"> that hides the QuickStatements info, so I needed to remove that as well in Module:WikidataIB. Hopefully, that's all working now. --RexxS (talk) 20:42, 9 September 2018 (UTC)

An option to output without tags seems to be a good idea. When this module is called by Module:Wikidata date and exposes QuickStatements syntax to be picked up for uploading the modules are chasing their own tail. --Marsupium (talk) 08:18, 1 November 2018 (UTC), 08:38, 1 November 2018 (UTC)

The code to strip out the extra tags, etc. is quite short:

	-- this may have QuickStatements info appended to it in a div, so remove that
	fdate = fdate:gsub(' <div style="display: none;">[^<]*</div>', '')
	-- it may also be returned wrapped in a microformat, so remove that
	fdate = fdate:gsub("<[^>]*>", "")

So it could be made into a switch within Module:Complex date, but it's probably more robust to simply incorporate it within each module that uses [Complex date] if you know you don't want the extra tags in those instances. --RexxS (talk) 17:29, 2 November 2018 (UTC)

My edit was to a template, not a module, and, as my intermediate edit summary says, was: "adding hidden ISO date for use in hCalendar microformats (like {{start date}} on Wikipedia-en." Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 18 October 2018 (UTC)

Unnecessary dependency

This module requires Module:Linguistic at the top of the page, but then never actually uses it. Pppery (talk) 23:47, 13 September 2018 (UTC)

That's true, but don't you think that pinging User:Jarekt, the module's maintainer, as a courtesy, would be helpful? --RexxS (talk) 01:22, 14 September 2018 (UTC)

Great, thanks for noticing and alerting us. I also removed "module:Date" as it is not directly used. However both libraries are still used indirectly by other loaded libraries. --Jarekt (talk) 02:57, 14 September 2018 (UTC)

certainty parameter

Lately I added a new certainty parameter, with supported values: possibly, probably, presumably and circa. ("circa" can be also used as adjective). This parameter was added to allow compatibility with Wikidata's sourcing circumstances (P1480) qualifier when used to describe a date. I also modified Module:Wikidata date so we can do things like:

• {{Complex date|date=11|precision=century|certainty=possibly}} -> possibly 11^th century
  date QS:P,+1050-00-00T00:00:00Z/7,P1480,Q30230067
• {{#invoke:Wikidata date|date|item=Q20189729|property=P571}} -> probably after 1884
  date QS:P,+1884-00-00T00:00:00Z/7,P1319,+1884-00-00T00:00:00Z/9,P1480,Q56644435

--Jarekt (talk) 04:23, 22 September 2018 (UTC)

Good! Please review my minor edits to Module:Complex date/sandbox for inclusion next time you update the module. Johnuniq (talk) 01:28, 23 September 2018 (UTC)

Thanks, I will include those. --Jarekt (talk) 02:26, 23 September 2018 (UTC)

Unexpected trailing newline when QScode is output

@Jarekt: Currently "{{complex date|ca|date=1818}}foo" gives: "circa 1818

date QS:P,+1818-00-00T00:00:00Z/9,P1480,Q5727902

foo" with a newline behind the processed template. It seems to be caused by the <div> element used for the QScode. Replacing it with a <span> element like this seems to fix it. Thanks for taking a look at it, --Marsupium (talk) 16:18, 9 June 2019 (UTC)

Russian conjugation

I have no idea how to fix that, but most adjectives should put Russian век 'century' into genitive case, e. g. {{complex date|date1=1700|adj1=1st quarter|precision1=century}} should give "первая четверть XVIII века" not "первая четверть XVIII век". Ain92 (talk) 19:23, 8 August 2020 (UTC)

Issues per Wikidata Infobox

Please see:

Template talk:Wikidata Infobox#earliest end date (P8554) not displayed

(which may be archived soon) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 31 October 2022 (UTC)

Islamic months

Currently, {{complex date|date=1444-01-01|era=AH}} and {{complex date|islamic|2022-07-30|1444-01-01}} will result in 1 January 1444 AH and 30 July 2022 AD (1 January 1444 AH) respectively (intended use: files in subcategories of Category:Dawlat-e ʿAlliya-ye Iran (newspaper) by year).

I think that for Islamic dates, the module was not designed with more precision in mind than the year. However, is it possible to automatically "translate" the month number to an Islamic month, e.g. 1 Muharram 1444? Of course only when the date is marked as Islamic or the era as AH. --HyperGaruda (talk) 07:24, 18 February 2023 (UTC)

• If anybody could fix this, please add Solar_Hijri_calendar#Months as well (era=SH). Hanooz 08:12, 18 February 2023 (UTC)

This can be fixed, but it's complicated because it affects a lot of modules that this one relies on and a clean fix would affect them all. But a non-perfect fix would be possible I think using mw:Help:Extension:ParserFunctions##time's Islamic calender codes like "xmj" and so on. I've looked into this already some weeks ago, but it was too big of an issue for an easy fix. I hope someone will be able to take care of it. Jarekt, have you seen this section already? --Marsupium (talk) 11:00, 14 April 2023 (UTC)

@HyperGaruda and Marsupium: I can look into it. As I understand the intended outcome would be that for "islamic" dates while we alter the year we also alter month name and the date. I can write something similar to the code used for handling Julian dates, but use mw:Help:Extension:ParserFunctions##time for that. For example today's date in russian would be {{#time: xmj xmF xmY|now|ru}} -> "15 Джумада аль-уля 1446". --Jarekt (talk) 12:51, 14 April 2023 (UTC)

Yes, that sounds good. It would be nice in addition to simplify the example from above, so that instead of "{{complex date|islamic|2022-07-30|1444-01-01}}" one could write "{{complex date|islamic|2022-07-30}}" giving "30 July 2022 AD (1 Muharram 1444 AH)" in English. Because the underlying calculation for that is already provided by {{#time}}. --Marsupium (talk) 13:15, 14 April 2023 (UTC), edited 13:37, 14 April 2023 (UTC)

Current output of {{complex date}} for Islamic calendar dates can also be seen on Module talk:Complex date/testcases. Sorry for untidily putting the examples in that imperfect place! --Marsupium (talk) 13:47, 14 April 2023 (UTC)

Agreed, sounds good! Simplified the other way around would also be convenient, in case a file only shows an AH date, so that inserting an AH date results in both the AD and AH date. --HyperGaruda (talk) 11:12, 15 April 2023 (UTC)

Extra space

{{Edit request}} This template produces an extra space at the end:

• circa 1900
  date QS:P,+1900-00-00T00:00:00Z/9,P1480,Q5727902
  .
• circa 2 March 1900
  date QS:P,+1900-03-02T00:00:00Z/11,P1480,Q5727902
  .

Could someone fix this? Nosferattus (talk) 23:04, 28 June 2023 (UTC)

This must be an error on your side, Nosferattus. There is no spurious space on my machine. — Speravir – 00:25, 25 July 2023 (UTC)

@Speravir: Jarekt fixed it. Nosferattus (talk) 01:07, 25 July 2023 (UTC)

Sorry, my mistake, Nosferattus. (Or: Actually, disabling the edit request template had been forgotten.) — Speravir – 01:12, 25 July 2023 (UTC)