Module talk:ISOdate

Time zones

{{Editrequest}} As for Module:Date, I modified the sandbox version to handle time zones. The number of combinations of format strings was getting a bit out of hand, so this version parses date, time and time zone separately. Please examine and copy to the live module if desired. --ghouston (talk) 07:39, 6 December 2016 (UTC)

--ghouston, I am a bit afraid to split date and time parsing. The dates that have time are allowed to have 1 digit days or months because it is less likely that those will be confused with something else. Dates with year and month are much more restrictive with other string at the end and less restrictive if whole string matches. I would like to preserve that. Can we just add a standard case with time zone? --Jarekt (talk) 03:56, 10 December 2016 (UTC)

I overlooked that detail. I was puzzled about why it accepted 1 digit days and months at all, when it's not a valid ISO 8601 format. Would it be an option to simply reject them? I'm accepting all the time zone variations: Z, +hhmm, -hhmm, +hh:mm, +hh etc., (although only with a hyphen and not a Unicode minus sign) and time zones can be attached to times that have hours/minutes/seconds or just hours/minutes, so there are a lot of combinations. I guess it wouldn't be hard to add some code to reject the single digit days or months when there's no time attached. --ghouston (talk) 06:58, 10 December 2016 (UTC)

I made that last change, so now it will reject 1 digit days and months if the time isn't present. --ghouston (talk) 03:30, 30 December 2016 (UTC)

Now I'm not sure I understand what you mean. The current version accepts 1 digit days and months when the time isn't present, even if it's not the entire string. E.g., {{ISOdate|1-2-3 stuff}} gives 3 February 0001 stuff. --ghouston (talk) 21:49, 2 January 2017 (UTC)

Incorrect date for Ukrainian

In Ukrainian month should be in genitive case: 11 лютого 2017 instead of 11 лютий 2017:

11 February 2017 --Anatoliy (talk) 19:06, 11 February 2017 (UTC)

User:Ahonc now "{{ISOdate|2017-02-11|lang=uk}}" gives "11 лютого 2017" --Jarekt (talk) 21:17, 11 February 2017 (UTC)

Unicode dates

@Jarekt: Line 58 mw.ustring.match( input, '^+?(-?%d%d?%d?%d?)-' ) allows unicode dates such as those in File:Baleghata_khal.png, but line 60 mw.ustring.format( '%04i', input ) does not allow those and fails with Lua error in Module:ISOdate at line 60: bad argument #2 to 'format' (number expected, got string). How should this be fixed? --Zhuyifei1999 (talk) 21:55, 24 August 2017 (UTC)

Zhuyifei1999, Yes I see {{ISOyear|০৪-১১-২০১৬}} gave error. I think it is fixed now. --Jarekt (talk) 02:42, 26 August 2017 (UTC)

RTL bug

Hi. The module shows the date in wrong order for rtl user. Could you, please, add ‎ just after the comma? Thank you. IKhitron (talk) 15:53, 12 June 2018 (UTC)

IKhitron, Lets look at some examples:

• {{ISOdate|1999-08-18|lang=he}} gives "‏18 באוגוסט 1999‏"
• {{ISOdate|1999-08-18|lang=fa}} gives "‏۱۸ اوت ۱۹۹۹‏"

How should they be modified? --Jarekt (talk) 20:25, 12 June 2018 (UTC)

The date is broken, of course. But I do not think you can do something here, without customizing for each language. I spoke about date and time together, with one of them in the middle of other:

• {{ISOdate|1={{Commons:Picture of the Year/2017/Rules/Time/data|r1end}}}} gives "‏24 ביוני 2018‏, 23:59:59"

Thank you, Jarekt. IKhitron (talk) 20:52, 12 June 2018 (UTC)

IKhitron, I see what the issue is: {{ISOdate|1={{Commons:Picture of the Year/2017/Rules/Time/data|r1end}}|lang=he}} gives "‏24 ביוני 2018‏, 23:59:59". It is not an issue with Module:ISOdate, but with Module:Date and Module:I18n/date where we do "customizing for each language":

• {{#time: j xg Y, H:i:s|2018-06-24 23:59:59|he}} gives "24 ביוני 2018, 23:59:59" (this is current setting for Hebrew)
• {{#time: j xg Y,"‎"H:i:s|2018-06-24 23:59:59|he}} gives "24 ביוני 2018,‎23:59:59"
• {{#time: Y "& lrm;" xg "& lrm;" j,"& lrm;" H:i:s|2018-06-24 23:59:59|he}} gives "2018 ‎ ביוני ‎ 24,‎ 23:59:59"

Would the last option be correct? --Jarekt (talk) 04:22, 13 June 2018 (UTC)

Well, neither. But if you fortunately do have per language customization, Jarekt, here is the right code: {{#time: "<span dir=rtl>"j xg Y"</span>", H:i:s|2018-06-04 23:59:59|he}}. Tests:

4 ביוני 2018, 23:59:59

4 ביוני 2018, 23:59:59

Thank you. IKhitron (talk) 10:27, 13 June 2018 (UTC)

 Done IKhitron I deployed your suggested formatting for Hebrew. Thanks. --Jarekt (talk) 12:10, 13 June 2018 (UTC)

Thank you very much for your help, Jarekt. IKhitron (talk) 12:12, 13 June 2018 (UTC)

Implement non-silent error handling for impossible dates

Creator:Francisco Sans Cabot gives as birth date "1828-94-09". This module silently swallows the impossible part: {{ISOdate|1828-94-09}} gives "1828". I do not think that is a good idea. (The page shows up in Category:Creator templates with Wikidata link: mismatching birthdate, but should be caught by a filter easier to check than that category.) Impossible dates should at least get sorted into a category like Category:Pages using Complex date template with incorrect parameter and maybe also a rendered warning rendered for logged in users to prevent them from getting into the wiki. Is there any reason against this? Thanks in advance, --Marsupium (talk) 18:44, 19 September 2021 (UTC)

Marsupium, As I recall I did try to add some maintenance categories to this module, but discovered that it was breaking some pages where {{ISOdate}} or {{ISOyear}} template is used to create category or template names. Those 2 templates are much older than Module:ISOdate and they are used sometimes in some unusual ways. That said, I can probably add maintenance categories when calling from other modules. --Jarekt (talk) 04:38, 3 February 2022 (UTC)

Just to add another example: This version of Creator:Édouard Rod contained "1857-04-31" which is displayed as "1 May 1857" (here current output of {{ISOdate|1857-04-31}}: 1 May 1857). That looks maybe even more problematic to me than the other case. Best, --Marsupium (talk) 17:10, 5 February 2023 (UTC)

@Jarekt I've just stumbled upon a next case in Creator:Borys Herasymovych, so I've come back here and looked into it a bit more. It turns out the quirkiness of handling "1857-04-31" is caused by function p.clean_datevec()'s maxval not complaining and further processing by #time parser function:

{{#time: Y-m-d | 1857-04-31}} gives "1857-05-01" ("1857-05-01").

And obviously this day-of-the-month error depends on month context which makes it a bit harder to catch. But for erroneous numbers irrespective of context a start might be checking something like testing

if #datevec ~= #datenum then

after

	local datenum  = p.clean_datevec(datevec)

could be a start. Or do you still find the removed code you used initially to add maintenance cats?

An easy implementation that avoids breaking pages could be a new function p._DateWithError() returning an additional isInvalidDate value and make the current function p._Date() call it while dropping that value in output. What do you think? Thanks in advance, --Marsupium (talk) 09:50, 16 December 2023 (UTC)

Marsupium p.clean_datevec function's job is to convert a date string to something that will not break {{#time: Y-m-d}}, dropping accuracy when necessary. It "fixes" months, days, hours, minutes and seconds. I agree that it would be good to track bad dates (hopefully someone will come and fix them), I feel like I do care about bad day and month numbers and not so much about hours, minutes and seconds. Maybe we can write a separate function to check validity of YYYY-MM-DD and YYYY-DD dates. Modules for Information, Artwork, Creator and Complex_date templates can call this function and add error categories if errors are detected. --Jarekt (talk) 02:45, 18 December 2023 (UTC)

Thanks for the reply! Okay, that sounds like a good approach! I have added a completely untested, freehand local function checkGregorianDateValidity(datenum) to Module:DateI18n/sandbox.

If you, I or someone finds the time and energy to write test cases and work on integration etc. that might be some point to start with. --Marsupium (talk) 11:48, 18 December 2023 (UTC)

Jarekt, a small update: I've added test cases for the function at Module:DateI18n/sandbox/testcases and fixed it to actually do what I wanted it to do. I think it could be integrated. Best, --Marsupium (talk) 15:01, 19 December 2023 (UTC)

Marsupium, I added a date validate function to Module:Calendar which can detect bad months and skip years. It converts from Gregorian date to en:Julian Day Number and than back to Gregorian date, and if the dates before and after are the same than the date is valid; otherwise is not valid. I also added testcases to Module:Calendar/testcases. What shall we call the new category, maybe Category:Pages with incorrect date. --Jarekt (talk) 00:18, 24 December 2023 (UTC)

Sorry for the late reply! I was distracted by holidays and didn't follow things here. On first impression the functioning looks good and also more simple than the approach I've followed above! What needs to be done to use this for dates handled by {{Creator}}, {{Artwork}} etc.? I've seen you've already implemented it. Wonderful and thank you! --Marsupium (talk) 12:18, 5 January 2024 (UTC), 16:17, 12 January 2024 (UTC)