Bug 265479 - ncal confuses Liechtenstein ISO 3166 code to represent Lithuania
Summary: ncal confuses Liechtenstein ISO 3166 code to represent Lithuania
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Only Me
Assignee: Warner Losh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-28 12:40 UTC by Piotr Smyrak
Modified: 2023-03-24 11:21 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Smyrak 2022-07-28 12:40:22 UTC
ISO 3166 [1] defines Lithuania code as LT, and LI to be Liechtenstein. 

The line 97 of usr.bin/ncal/ncal.c needs one char fix. 

1. https://en.wikipedia.org/wiki/ISO_3166-2:LT
Comment 1 Warner Losh freebsd_committer freebsd_triage 2022-07-28 17:38:30 UTC
Fixed in 6feb6b4ffc05
Will MFC in a day or three
Comment 2 commit-hook freebsd_committer freebsd_triage 2022-07-28 17:38:53 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=6feb6b4ffc0514f59da98992dffd88da472a4397

commit 6feb6b4ffc0514f59da98992dffd88da472a4397
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2022-07-28 17:34:38 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2022-07-28 17:35:50 +0000

    ncal: LT is the country code for Lithuania

    PR: 265479
    MFC After: 3 days

 usr.bin/ncal/ncal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 3 Ed Maste freebsd_committer freebsd_triage 2023-03-21 23:58:33 UTC
LT is indeed Lithuania, but is 1918 correct for the year that it switched?

https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_Gregorian_calendar_by_country
Comment 4 Piotr Smyrak 2023-03-22 08:35:43 UTC
(In reply to Ed Maste from comment #3)
Yes and no. Adoption of Gregorian calendar is more complicated then a programmer would want. Lithuania litterary went back and forth in time. 

Originally Lithuania as the Grand Duchy of Lithuania adopted Gregorian calendar in 1585. 3 years after Kingdom of Poland despite forming with the latter Polish Lithuanian Commonwealth (PLC). Then in 1795 the final third partition of Commonwealth was conducted and the remaining part of Lithuanian territory was annexed mostly into Russian Empire, but some was taken by Prussia. In 1800 tsarist regime absorbed new lands by conducting various reforms, and switched Lithuanian governorates back to Julian calendar. During the Great War, German armies conquered many Western provinces of Russian Empire, and being precise and railway people German staff switched over these provinces to Gregorian calendar in 1915. After the war a nation state of Lithuania was declared and it kept the new calendar. To make it more confusing the Lithuanian land annexed into Prussia were using the Gregorian calendar the whole time, as Duchy of Prussia (later Kingdom of Prussia) adopted it in 1612 long before the partitions of PLC.

PS. this is a simplified story. I have skipped few bits. :-)
Comment 5 Piotr Smyrak 2023-03-24 11:21:17 UTC
The problem is the matrix assigns to modern-day states events that happened, when these often did not exist. Ie. 1700-02-18 assigned to Germany is a Gregorian calendar switchover of German protestant states, catholic principalities did it way earlier. The same note applies to federal bodies like Netherlands and Switzerland. So this is bound to get messy.

Lithuanian (and Belorussian for that matter – note, absent from the matrix) case might be special in the sense, that this is one of few cases, where the Gregorian reform was undone. 

Thus currently the practical effect is if someone tries to use ncal to determine dates in Vilnius for years 1585–1800, one would get misleading Julian dates. If we change the value for Lithuania to 1585-12-21 the erroneous period would cover years 1800–1915/1918 by returning Gregorian dates.

I was aware of this, when filing the ticket, and saw no obvious solution. Thus decided to cover only the spec violation aspect in the report.