Template talk:Calendar date

Template

@Sir Joseph, Howcheng, and Dweller: This is a follow-up thread to the original thread at BotReq. Example use. 12 Jewish holidays are populated. -- GreenC 19:14, 24 August 2018 (UTC)[reply]

Design notes

Hebrew Calendar localfiles are not evenly covered up to 2100 because the hebcal.com API is not returning consistent data for some of them beyond a certain point. This appears to be a problem with their API which may be fixed in the future when they can be filled in.

-- GreenC 13:55, 27 August 2018 (UTC)[reply]

json vs Lua module discussion from IAN

Seems to me like that page should be a Module page, stored in a Lua table, since it's not hooking into a Javascript system but instead the Module. --Izno (talk) 15:59, 30 August 2018 (UTC)[reply]

That's probably what will happen but I used JSON for proof of concept, I like doing things 3 times over again :) Although honestly there is no major performance issue with mw.text.jsonDecode() vs. mw.loadData(), the JSON file will be more accessible to more users than Lua code would be, and JSON is now a universal format. If all your doing is storing configuration data that will be accessible to the largest number of users. -- GreenC 17:23, 30 August 2018 (UTC)[reply]

I assumed there wasn't a significant performance delta--my point was more that if you're handling data consumed by a Module, you should probably default to providing that data as a Module (a Lua table), unless there are other circumstances of interest (particularly, that the data to be consumed will be consumed by more than just a Lua module). I suppose if the template becomes widely used, it's going to end up template protected either way. (I didn't realize that JSON could be edited by anyone?) Lua does provide a better access point I think into the MediaWiki library, so constructs like your datasource probably would not be needed, or not needed in the same way (since e.g. I'm pretty sure Lua can manipulate the time display directly, so you don't need to provide the time parserfunction in the JSON, just the final format). --Izno (talk) 21:58, 30 August 2018 (UTC)[reply]

Date calculators are handled as third-party plugins which users can add or change as they are developed. There are too many varieties and difficulties to build a general purpose moveable date calculator. For example, just to calculate Easter there is Module:Easter a significantly complex affair. Something similar is needed for Hanukah but doesn't yet exists, so it uses a local data file with dates listed up to 2050. If Wikidata can provide Hanukah data it will be able to pull it from there also. Then there are 100s of 1000s of other moveable dates to tackle, some easy to calculate, some hard, some impossible without data files. Anyway, the template doesn't need to be modified with each case as the calculators are self-contained in datasource. -- GreenC 23:17, 30 August 2018 (UTC)[reply]

I guess my concern is that you don't really have static data in your JSON file then and so you shouldn't be storing it as if you do. Does jsonDecode accept data that might change? --Izno (talk) 23:24, 30 August 2018 (UTC)[reply]

Notice the "YYYY" in the calculators. This gets replaced with the target year |year=. The text in datasource is not live only an instruction for what the template should execute (preprocess) during runtime. Anyway I'm probably ditching JSON entirely in the latest revision, there are a couple advantages to going native Lua table. -- GreenC 00:06, 31 August 2018 (UTC)[reply]

GreenC, there is one important performance difference: a lua data module is only loaded once when parsing a page, while the json code will be loaded and parsed for each template transclusion in the page being parsed. Just so you know. —TheDJ (talk • contribs) 08:01, 31 August 2018 (UTC)[reply]

TheDJ Thanks. Yes I read last night there was some magic with mw.loadData() and started converting to Lua. This is the third time I've converted the data so hoping it will be final! -- GreenC 11:50, 31 August 2018 (UTC)[reply]

Wikidata

There was a discussion on Wikidata (Aug, 25-29 2018) about integration with this template, and long story short to produce moveable dates, in most cases, requires running a query and Lua can't do it. Example query for Hanukkah. -- GreenC 21:23, 31 August 2018 (UTC)[reply]

Data cite

@Pppery: - The citation information should not be removed from the Events Module.[1] The template can be used in non-mainspace pages etc.. the citation information is there for whoever wants to use it for whatever purpose, including in non-mainspace. It is an optional command argument, if you don't want it in your mainspace page then don't use the |cite= argument. There is no reason to delete it from the Module itself.

Also, self-referential is not entirely clear, it's courtesy information so readers understand the dates are being calculated and where to find the calculator, should they wish to verify the dates. Our primary objective is Verification, a core pillar and policy of Wikipedia, WP:SELFREF is a weaker MOS Guideline and should not trump our primary goal of Verifiability. Also it is a courtesy to notify before making major changes, particularly a change based on Guideline vs Policy. And you should be using a Sandbox instead of editing on the fly and causing breakages. -- GreenC 17:31, 17 February 2019 (UTC)[reply]

There are a grand total of eight pages outside of mainspace that use this template. Four of them are part of the documentation of the template itself. That leaves only four pages, rendering any argument of "this can be used outside of mainspace" moot. Likewise, including a link to the module does not provide a verifiability benefit: Module:Easter and Template:Calendar date have no references no references, and Template:Hebrew year does not reference a generalized method of converting dates into the Hebrew calendar. Even if there were references on those pages, it would be better to cite them directly rather than force readers looking for citations into a editor-oriented template or module documentation page. And this issue transcends individual articles: a link to a editor-facing template or module is no more acceptable on one article than another, hence not specifying |cite= in some articles is not a solution. You are right that maybe I should have used the sandbox, but one is not required to notify before making major changes: WP:BOLD says otherwise. {{3x|p}}ery (talk) 19:07, 17 February 2019 (UTC)[reply]

BOLD doesn't apply to Template space, nor does BRD or 3RR (notice I did not revert you). We try to keep changes to a minimum due to technical considerations which is why we use sandboxes and post a notice on talk pages before making live. If the edit might be controversial work the issues out beforehand to avoid needless reverts. |cite= is off by default, if someone wants to use it for whatever purpose that is their choice, there is no reason to remove it from the source code. The calculator modules are open source and demonstrably accurate, it is correct to point readers to them as the source that generated the dates where needed (not always the case calculators are used). -- GreenC 21:41, 17 February 2019 (UTC)[reply]

You haven't adressed the fact that Module:Easter/doc, Template:Calendar date/doc and Template:Hebrew year/doc are pages oriented at editors using the template rather than readers looking for a source (as they should be). Furthermore, Wikipedia is explicitly not a reliable source, so, even ignoring the self-reference issues, the code of Wikipedia templates and modules should not be cited. {{3x|p}}ery (talk) 22:13, 17 February 2019 (UTC)[reply]

We use Modules and Templates everywhere, they are an acceptable method and "source" for generated page content so long as it works. One can't say on the one hand it is an unreliable source then continue to use it - is the module the source or not? The |cite= was added because this template was once removed from an article because it lacked information where the dates came from, so it was added as a courtesy for users where and how the dates are generated - not everyone is clued how to find that information, evidently. Wouldn't get too stuck on the exact meaning of a citation, citations sometimes contain simply notes. The important thing is the core policy of Verifiability. -- GreenC 14:33, 18 February 2019 (UTC)[reply]

Maybe it would help to rename |cite= -> |note= to avoid confusion about RS and SELFREF. -- GreenC 15:16, 18 February 2019 (UTC)[reply]

Maybe, although it does provide a valid citation for the localfile-generated dates. Regardless, I've listed this discussion at Wikipedia:Third opinion. {{3x|p}}ery (talk) 16:01, 18 February 2019 (UTC)[reply]

There are a grand total of 52 articles linking to module namespace, the vast majority of which are modules reporting an error to their users. {{3x|p}}ery (talk) 16:22, 18 February 2019 (UTC)[reply]

Edit request

This edit request to Template:Calendar date/Configuration.json has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Change content model to Wikitext and redirect to Module:Calendar date/Events. This template has been implemented using a Lua data page rather than a JSON page, so there is no need to keep the old JSON around. {{3x|p}}ery (talk) 00:11, 19 February 2019 (UTC)[reply]

I believe Wikipedia:Interface administrators' noticeboard have the perms to change content type. Request. -- GreenC 00:38, 19 February 2019 (UTC)[reply]

Per Special:UserGroupRights, ordinary admimistrators have the editcontentmodel right necessary to perform this request. {{3x|p}}ery (talk) 00:50, 19 February 2019 (UTC)[reply]

Done — JJMC89 (T·C) 02:15, 19 February 2019 (UTC)[reply]

URL not good

The URL https://www.hebcal.com/holidays/passover no longer works, and I suppose the same is true for the other Jewish holidays. It should be just https://www.hebcal.com/holidays now. Eric Kvaalen (talk) 10:52, 23 April 2019 (UTC)[reply]

Replaced with https://www.hebcal.com/holidays/pesach .. others are OK just a name alias issue. -- GreenC 13:14, 23 April 2019 (UTC)[reply]

Dates to 2100

Moved from Module talk:Calendar date/localfiles/Tzom Tammuz

– * Pppery * _{it has begun...} 23:14, 31 December 2019 (UTC)[reply]

@GreenC: I just created this file. How did you get dates up to 2100 for the other local data files? I couldn't figure out where to get them from hebcal. Thanks. —howcheng {chat} 15:39, 31 May 2019 (UTC)[reply]

@Howcheng: I made a program that retrieves data from the Hebcal API. However, the API has gaps in coverage. For example, to see all Holidays in June 2018 [2]. There is no Tzom Tammuz listed (should be June 30 at sunset). Because Fast Days can't be calculated(?) Hebcal probably manually adds them thus they do not go forward as far as calculated dates. No good solutions, maybe a reminder somehow to keep the file updated or find a different source. -- GreenC 18:49, 31 May 2019 (UTC)[reply]

Requested move 17 June 2019

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved. (non-admin closure) — Newslinger talk 06:46, 25 June 2019 (UTC)[reply]

– Names of subpages of modules and templates should be lowercase per convention. * Pppery * _{it has begun...} 23:34, 17 June 2019 (UTC)[reply]

Support per nomination. ~SS49~ {talk} 02:17, 18 June 2019 (UTC)[reply]
support- per convention.___CAPTAIN MEDUSAtalk 22:14, 20 June 2019 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Broken URL

The URL to a Naval Observatory server being surfaced by this template in the infobox at Ash Wednesday is not working as at 09:19, 15 March 2021 (UTC). Thanks. — Spike Toronto 09:19, 15 March 2021 (UTC)[reply]

According to https://www.usno.navy.mil/

The USNO websites aa.usno.navy.mil, ad.usno.navy.mil, aristarchus.usno.navy.mil, maia.usno.navy.mil, rorf.usno.navy.mil, toshi.usno.navy.mil, and tycho.usno.navy.mil are undergoing modernization efforts. The expected completion of the work and the estimated return of service is Fall 2020, subject to change due to potential impacts of COVID-19.

Guess we wait. -- GreenC 14:15, 15 March 2021 (UTC)[reply]

@GreenC: Thank you for looking into this. Thanks!

— Spike Toronto 21:52, 15 March 2021 (UTC)[reply]

@SpikeToronto: It is still down. The URL is used in Module:Calendar_date/events for 7 holidays (search on ".mil"). The URLs could be removed, or replaced with a different source. -- GreenC 15:37, 29 May 2021 (UTC)[reply]

frame:preprocess and some other things

Maybe better frame:expandTemplate and then frame:callParserFunction? Can I try it on Module:Calendar date/sandbox?

Also, I would like to migrate one or two functions from my ru:Module:Calendar for {{OldStyleDate}}.

I would like an international, module-friendly date mechanism (see phab). I will be grateful if you allow me to use your sandbox for implementation — there are already functions in it that I use. I can use Module:DatesWD (now I see I need to make it WikiData-friendly 😆), but your title is better. ·Carn·!? 14:57, 29 May 2021 (UTC)[reply]

I'll work separately, sorry to bother! ·Carn·!? 09:37, 2 June 2021 (UTC)[reply]

Chuseok / Tsukimi / Mid-autumn festival calculated dates are wrong for 2024

The dates for Chuseok (Korea), Tsukimi (Japan) and Mid-autumn (China) holidays are coming up wrong for 2024. The holiday is day 15 of the 8th lunar month. In 2024 that new moon is 2 Sept^[1] so the holiday is 17 Sept^[2]. (Chuseok and Tsukimi are observed for several days centered around that date). The template comes up about 10 days earlier:

{{Calendar date |holiday=Chuseok |year=2024}} -> 16 September 2024 – 18 September 2024.

{{Calendar date |holiday=Tsukimi |year=2024}} -> 17 September 2024 – 20 September 2024.

{{Calendar date |holiday=Mid-autumn festival |year=2024}} -> 17 September 2024.

-- M.boli (talk) 21:39, 20 August 2022 (UTC)[reply]

(Note to future readers: after the bug is fixed the above comment will show correct dates instead of 10 days early. -- M.boli (talk) 12:35, 24 August 2022 (UTC))[reply]

References

^ "2024 Phases of the Moon". Griffith Observatory.
^ "Chuseok 2022, 2023 and 2024". South Korea Public Holidays, websites for Japanese and Chinese public holidays produce similar results}}

M.boli: This template uses Module:Calendar_date/events to define holidays. Looking at the entry for Chuseok, it uses {{ctime:x|YYYY|8|14}} to calculate the date, where "YYYY" is the year in question. Thus {{ctime:x|2024|8|14}} = 2024-09-16 which is the date noted above. I don't know how {{ctime:x}} works is the problem with {{ctime:x}} or the 8|14 parameter? -- GreenC 03:37, 21 August 2022 (UTC)[reply]

Hi User:Gonnym, do you have any idea why the above are not working? -- GreenC 03:47, 21 August 2022 (UTC)[reply]

Yup! The problem is in {{ctime:x}}. It gets the dates correct for 2021 to 2023, but 2024 breaks. Lunar new year for 2024 is also computed 10 days early:

{{ctime:x|2024|1|1}} -> 2024-02-10, but it should be 2024-02-10.

-- M.boli (talk) 05:11, 21 August 2022 (UTC)[reply]

2025 looks off also : {{ctime:x|2025|1|1}} -> 2025-01-29, should be 2025-01-29 -- GreenC 05:24, 21 August 2022 (UTC)[reply]

Passover incorrect date

This template is giving the wrong date of Passover at Passover Seder for this year. It is saying it begins on the night of April 6th. However, the correct info is the night of April 5th. I commented out the use of the template there for now. - UtherSRG (talk) 00:40, 5 April 2023 (UTC)[reply]

Thanks, GreenC! - UtherSRG (talk) 10:47, 5 April 2023 (UTC)[reply]

[1] "2024 Phases of the Moon". Griffith Observatory.

[2] "Chuseok 2022, 2023 and 2024". South Korea Public Holidays, websites for Japanese and Chinese public holidays produce similar results}}

[1]

[2]