The template's output reads shity when the dates are in different years. E.g. {{OldStyleDate|January 10|1906|December 28, 1905}} becomes January 10 [O.S. December 28, 1905] 1906 rather than January 101906 [O.S. December 28, 1905]. There should be an optional fourth paramater to handle the second year properly. --FordPrefect4221:57, 31 January 2007 (UTC)[reply]
I'm going to update this ancient template to reflect contemporary font guidelines stipulating that prose text should remain consistent in size and format, bearing in mind that this template transcludes as regular text inside prose segments. Snowtalk15:11, 18 January 2015 (UTC)[reply]
This template (and its variants) currently points to Old Style and New Style dates. Following extensive and long-running discussion at talk:Old Style and New Style dates, much of which revolved around the issue of duplication/forking of content with Adoption of the Gregorian calendar, the former article has been revised extensively so that it addressed specifically (and only) the adoption of the Gregorian calendar in Great Britain and its colonies, as it is here where the terms O.S. and N.S. are most used. However, other jurisdictions also changed to the Gregorian calendar and the term 'old style' is used there too (both within en.wiki and in English-language resources externally). In respect of readers coming to Wikipedia to clarify what is meant by a reference to 'old style' in an external medium, there is a hat-note in Old Style and New Style dates that directs readers to the Adoption article. For the internal references (which are particularly prevalent in articles about Russia and Russians), a change is needed. So I would like to make the following proposal:
that, when the template generates a wlink to 'O.S.', the target becomes Adoption of the Gregorian calendar rather than this article.
Thus the template would become: {{{1}}} [[[Adoption of the Gregorian calendar|O.S.]] {{{3}}}]{{#if: {{{2|}}}| {{{2|}}}|}}
(instead of {{{1}}} [[[Old Style and New Style dates|O.S.]] {{{3}}}]{{#if: {{{2|}}}| {{{2|}}}|}} ).
The effect will be not be evident in the articles that use the template, they will look exactly the same. The only people that will be aware of the change will be those who wonder what the O.S. means and click on it. If this proposal achieves consensus, the 'sister' templates will be changed equivalently. Comments? --John Maynard Friedman (talk) 00:07, 1 December 2016 (UTC)[reply]
As there have been no comments, I have changed these templates. However, given further discussion at talk:Old Style and New Style dates, some additional material will be added to address the use of OS/NS notation in modern English language texts that deal with dates of events in Russia around the time of the revolution. --John Maynard Friedman (talk) 11:38, 9 December 2016 (UTC)[reply]
I have revered the change. I do not agree with changing a link to an article about new and old style dating to an article about a calendar particularly when. If you insist on educing the article Old Style and New Style dates so that its meaning is not comprehensive enough for this redirect then expand the article not redirect this to something that does not even mean old style date but instead means one of two possible new style dates. -- PBS (talk) 18:50, 31 December 2016 (UTC)[reply]
I tend to agree with John Maynard Friedman on this. I was reading an article about a Russian composer, and was surprised to find that clicking on the O.S. link brought me to an article about "the 18th-century changes in calendar conventions used by Great Britain and its colonies", with no information whatsoever about Russian use. A link to the "Adoption" article would be way more useful. —capmo (talk) 14:03, 5 June 2018 (UTC)[reply]
MOS:DATE requires a comma after the day when using mdy dates, e.g. "February 2, 1905". The example given here has no comma: {{OldStyleDate|February 2|1905|January 20}} produces February 2 [O.S. January 20] 1905. This should be February 2 [O.S. January 20], 1905. The template currently doesn't recognize that mdy is in use and so doesn't add the necessary comma. Hairy Dude (talk) 17:15, 22 February 2020 (UTC)[reply]
Automatic recalculation or verification of manually entered parameters
Tell me, are you interested in such features? I have already made such a module and now I am implementing it in ru.wp (collect the parameters by the bot and check that the work of the template is not changing in any way for the correct parameters). For example, articles templates in which data is presumably incorrect can be placed in a separate hidden category. However, in such a situation it will obviously be more difficult to change the display format of the template. See also T276471. ·Carn·!?16:21, 4 March 2021 (UTC)[reply]
{{OldStyleDate|2 February 1905|link=yes}} → 2 February [O.S. 20 January] 1905
{{OldStyleDate|February 2, 1905|link=yes}} → February 2 [O.S. January 20], 1905
Support for the old three-parameter invocation (but with a comma after "]" in the MDY date format):
{{OldStyleDate|2 February|1905|20 January}} → 2 February [O.S. 20 January] 1905
{{OldStyleDate|February 2|1905|January 20}} → February 2 [O.S. January 20], 1905
(This is a temporary compatibility feature that will be removed once all errors marked by a special hidden category are resolved.)
The bot must support the following features:
Replacement of old three-parameter {{OldStyleDate}} invocations (3054 transclusions as of 26 April 2021) with new one-parameter invocations (if the computed date doesn't match the manually specified date, don't replace and add the special hidden category):
{{OldStyleDate|2 February|1905|20 January}} → {{OldStyleDate|2 February 1905}}
Replacement of {{OldStyleDateDY}} invocations (209 transclusions as of 26 April 2021) with new one-parameter {{OldStyleDate}} invocations (if the computed date doesn't match the manually specified date, don't replace and add the special hidden category):
{{OldStyleDateDY|10 January|1706|30 December 1705}} → {{OldStyleDate|10 January 1706}}
{{OldStyleDateNY}} invocations (201 transclusions as of 26 April 2021) will have to be replaced with new {{OldStyleDate|…|year=no}} invocations manually as it is impossible to automatically deduce the year. I can do this work when the new implementation of the template goes live. I can also resolve the errors marked by the special hidden category and delete {{OldStyleDateDY}} and {{OldStyleDateNY}} templates once all their transclusions are gone.
My thanks too. When you say will have to be replaced with new {{OldStyleDate|…|year=no}} invocations manually as it is impossible to automatically deduce the year, may I assume that these will also go in the special category for checking? --John Maynard Friedman (talk) 08:03, 26 April 2021 (UTC)[reply]
Now, while in ru.wp, I will begin to redo the module, taking out internationalization data separately. Along the way, it turns out that it is desirable to take out part of the module's functionality so that it can be used in other modules, so I don't promise a quick result. But yes, I will try to separate such cases into a separate category. ·Carn·!?10:01, 27 April 2021 (UTC)[reply]
I think maybe that I wasn't being clear (and now make a suggestion that may make the coding more general and thus simpler): could you simply identify the cases where conversion fails for any reason, since they will all need manual intervention. Of course 'no year specified' and 'arithmetic error' are going to be the most common but no doubt there are other oddities. --John Maynard Friedman (talk) 11:03, 27 April 2021 (UTC)[reply]
Perhaps it would be easier to write the new implementation of {{OldStyleDate}} from scratch, as its feature set is very simple (simpler than what is required in the Russian Wikipedia)? Just a thought. — UnladenSwallow (talk) 23:03, 27 April 2021 (UTC)[reply]
What I meant is that it is impossible to write a bot that would automatically convert {{OldStyleDateNY}} to the new {{OldStyleDate}}, as the difference between Gregorian and Julian dates depends on the year (which is absent in {{OldStyleDateNY}}), therefore, I/we will have to do this conversion manually. There's no point in adding the special hidden category to pages that transclude {{OldStyleDateNY}}, as we already have the list of such pages. For {{OldStyleDate}} and {{OldStyleDateDY}}, you are right that we must add the special hidden category for any type of conversion mistake so it can be fixed by a human. — UnladenSwallow (talk) 22:47, 27 April 2021 (UTC)[reply]
What makes you think it would be easier than on ru.wp? Do they have two formats of date (DMY, M,DY) like we do? I doubt it. Both WPs have to cover 1752 and 1917.
The present templates can't handle dates after 17 Dec (OS) or before 13 Jan (NS) because the year number changes. It needs a rewrite and this proposal is already running on ru.wp so let's grab the offer with both hands. --John Maynard Friedman (talk) 23:32, 27 April 2021 (UTC)[reply]
Sorry for delay, yes, we have several formats, and we have some templates copied from another wikis, i copied the functions I'll need, though I don't see that there is some module for modules for date parsing (maybe I hasn't looked for it properly). ·Carn·!?16:00, 7 June 2021 (UTC)[reply]
See Template talk:OldStyleDate/temp#Test - I may have confused the new and old date styles, but in principle it is clear that instead of a family of templates, one universal one can be made, which will itself eliminate duplication of the year (and month, maybe). Partial dates without year specified, of course, cannot be transferred from one date style to another, but we can detect the abnormal difference between them. ·Carn·!?12:09, 14 June 2021 (UTC)[reply]
JULGREGDATUM template
I occasionally translate pages from German to English, where the English language page is either missing or has less information. I just came across the template JULGREGDATUM which appears to do a similar, but IMO better, job in German language. When I translated a page incorporating this template without change, it appeared to do the same as the template OldStyleDate, but the result is much less readable and useful than the German template JULGREGDATUM.
I.e. the result of {{JULGREGDATUM|23|11|1903|Link=1}} in a German language page is '10. Novemberjul. / 23. November 1903greg.'
Whereas using the same template in an English page produces '23 [O.S. 1903] 11' which is far less readable and does not include the date conversion.
Attempting to use the OldStyleDate template produces poorly readable results, e.g.
{{OldStyleDate|23|11|1903}} also produces '23 [O.S. 1903] 11' which is far less readable.
I am British English and the terms Old Style (O.S.) and New Style (N.S.) were not familiar to me, although Julian and Gregorian calendars are, whereas presenting 2 dates with superscripts including links to Gregorian and Julian calendar descriptions is much more readable and usable. The automatic date conversion is also useful.
I have never created a template before, but I will see whether I can create an English version of JULGREGDATUM. I will call it JULGREGDATE or JulGregDate.Lkingscott (talk) 09:09, 18 May 2023 (UTC)[reply]
But the correct way to use {{OldStyleDate}} for that example is {{OldStyleDate|23 November|1903|10 November}} which produces 23 November [O.S. 10 November] 1903.
Have you read Old style and new style dates? It is very complicated: Catholic Europe adopted the Gregorian calendar in 1582, Protestant Europe took up to 200 years to follow suit. Orthodox Europe took even longer (civil calendar only). Adoption of 1 January as start of year varied, even in (what was to become) the United Kingdom: Scotland did so from 1600, England waited until 1752. So 1 March 1700 in Scotland was on an entirely different day than 1 March 1700 in England, let alone in France. It can't be done automatically without knowing the context. --𝕁𝕄𝔽 (talk) 09:58, 18 May 2023 (UTC)[reply]
I wonder if you have set us off diwn the garden path by raising OS/NS? I'm not sure that it matters. Today is 18 May 2023 Gregorian, which equates to 31 May 2023 Julian. But that still leaves us with the start of year problem: 1 March 1700 Julian in Scotland equated to 1 March 1699 in England. Just to ignore the "start of year" problem is common but is generally explained beforehand. It can really mess up historical narrative if done blindly. --𝕁𝕄𝔽 (talk) 10:44, 18 May 2023 (UTC)[reply]
It could be done algorithmically, but the coding might be "entertaining". Something like JulToGreg|yyyy|mm|dd|soy=ddmm where soy= (start of year) is ignored from 1753 onwards and mandatory for earlier years. No doubt chatgpt will write it for you in a few milliseconds. 𝕁𝕄𝔽 (talk) 11:28, 18 May 2023 (UTC)[reply]
Genuine Old Style template wanted
This template, in its several current variations, gives priority to the New Style date – i.e., it treats New Style as the default, "official" date, with the Old Style equivalent as an explanatory aside in square brackets: e.g. "4 May [O.S. 23 April] 1710". However, this is at odds with standard practice in historical writing about Britain and its colonies in the period 1582–1752, which is to retain the Old Style day and month as default, with the New Style equivalent given, if at all, as an aside for the benefit of a minority of readers who may want to map events in Britain against those in continental Europe, or work out the exact length of a timespan that traverses the 1752 calendar change, or undertake astronomical calculations. This convention is also wikipedia policy, per MOS:OSNS: Dates after 4 October 1582 in a place where the Julian calendar was observed should be given in the Julian calendar. We therefore need an equivalent template that gives priority to the Old Style date – i.e. that would render the date above in the form "23 April [N.S. 4 May] 1710". Can somebody produce that? GrindtXX (talk) 00:29, 7 June 2025 (UTC)[reply]
Does this do what you want? (I made a new template:OS(NS)template:Old Style to New Style (shortcut {{OS2NS}}, though its name may not be accepted.)
{{OS2NS|20 January |1905|20 February}} → 20 January [20 February N.S.] 1905
It doesn't do the calculation for you, but then neither does {{OldStyleDate}}. Which is why you make a silly error like a 30 day shift that never happened, as in this case.
That looks good to me – except that in your draught ('Usage', first sample structure) you've put 'OS' twice, where the second should be 'NS'. No, I wasn't proposing a template that did the calculation (which would be great, if achievable, but presumably incredibly difficult to construct). I don't have any firm preferences for a long name, but perhaps put the word 'conversion' in there somewhere. GrindtXX (talk) 16:59, 8 June 2025 (UTC)[reply]
Sorry, I don't see what you mean? Would you prefer
20 January [2 February N.S.] 1905
instead of
20 January [N.S. 2 February] 1905
(or is just that my ultra-clever /s choice of name has caused confusion?)
My initial point was just that you've typed {{OS2NS|OS day and month|year|OS day and month}} where I assume you meant {{OS2NS|OS day and month|year|NS day and month}}.
On the whole my preference would be to have the N.S. after the day/month (2 February N.S.), but I don't feel particularly strongly on the matter.
So I have! Will fix asap. And I agree, 2 February NS is better. But what about February 2 NS? Should it be February 2, NS? 𝕁𝕄𝔽 (talk) 20:51, 8 June 2025 (UTC)[reply]
Perhaps the comma is a good idea in month-day dates – it looks a bit confusing without. No further comments: all looks good. GrindtXX (talk) 13:23, 9 June 2025 (UTC)[reply]
Good, that's what I thought too. The code for the presentation is very simple, real "monkey see, monkey do". So if you want a comma, go ahead and just add it:
Usage: {{Old Style to New Style|January 20, |1905|February 2, }}
I have a strong suspicion that whoever first created the OldStyleDate template had A Cunning Plan to calculate it by adding the requisite number of days according to century only to realised that the 1 January v 25 March start of year was going to make it all too difficult. 𝕁𝕄𝔽 (talk) 16:27, 9 June 2025 (UTC)[reply]
Does it cope with England & possessions delaying start of year to 25 March? (which is not an issue for Russian dates). --𝕁𝕄𝔽 (talk) 16:34, 2 September 2025 (UTC)[reply]
That is the big and annoying stumbling block here. An algorithmic solution would save a lot of time, trouble and errors. 𝕁𝕄𝔽 (talk) 19:37, 2 September 2025 (UTC)[reply]
