Skip to content

Conversation

@kurtkeller
Copy link
Contributor

@kurtkeller kurtkeller commented Nov 9, 2024

Proposed change

Like in other German speaking countries, January 01 is called "Neujahr" in Switzerland, not "Neujahrestag". "Neujahrestag" would be wrong anyway, it would be "Neujahrstag".

Type of change

  • New country/market holidays support (thank you!)
  • Supported country/market holidays update (calendar discrepancy fix, localization)
  • Existing code/documentation/test/process quality improvement (best practice, cleanup, refactoring, optimization)
  • Dependency update (version deprecation/pin/upgrade)
  • Bugfix (non-breaking change which fixes an issue)
  • Breaking change (a code change causing existing functionality to break)
  • New feature (new holidays functionality in general)

Checklist

Like in other German speaking countries, January 01 is
called "Neujahr" in Switzerland, not "Neujahrestag".
"Neujahr*e*stag" would be wrong anyway, it would be
"Neujahrstag".
@KJhellico
Copy link
Collaborator

Here is "Neujahrstag". This is an official source, as far as I understand.

@kurtkeller
Copy link
Contributor Author

Here is "Neujahrstag". This is an official source, as far as I understand.

That's correct, I'm familiar with that document. It is a document which specifies which days are counted as holidays for legal matters, for example to calculate whether you filed claims within the specified period of time.

short answer:
The current spelling of "Neujahrestag" (check the 2nd "e") in the python file is wrong. "Neujahr" is what people actually use. "Neujahrstag" is understood and would be the correct spelling you also find in the referenced document.

long answer:
You won't find "Neujahrestag" (as in the python file) anywhere in that document. The document uses "Neujahrstag", not "Neujahr e stag". Nevertheless what we really call it is "Neujahr", same as for Germany, Austria, Liechtenstein. The document also uses "Fahrtsfest" for Glarus (...subdiv_gl_public...) but we call it "Näfelser Fahrt" (the way it is in the python file). Furthermore the PDF document uses "Mariä Himmelfahrt" and "Mariä Empfängnis" in some places and in others "Maria ..." (ä vs a). The python file uses the traditional spelling throughout which is much more consistent. The PDF document uses the Italian names for Ticino (...ti...), French names for the French-speaking cantons and both French and German for the three cantons officially speaking both languages. The canton of Graubünden (...gr...) officially uses 3 languages: German, Italian and Romansh, but the document only uses German and Italian. (see: https://www.eda.admin.ch/aboutswitzerland/en/home/gesellschaft/sprachen/mehrsprachigkeit.html and https://www.fedlex.admin.ch/eli/cc/2009/821/en#art_21) The python file consistently uses the German names throughout. Switching to localized and even multi-language names could become messy. Besides, the PDF document also clearly states on page 2 that only August 1st is a holiday defined on national level. The other three holidays configured in _populate_public_holidays actually are are not national holiday but holidays defined on cantonal (subdiv) level, albeit they are holidays in all 26 cantons. Also here, changing that in the python file might be counter-productive.

@KJhellico
Copy link
Collaborator

Yes, I mean, let's change it to "Neujahrstag".

@arkid15r
Copy link
Collaborator

@kurtkeller does "Neujahrstag" look like a meet in the middle option?
Thanks for your native language experience input!

@kurtkeller
Copy link
Contributor Author

Yes, "Neujahrstag" is a good enough compromise.

After discussions settled on removing the typo and use "Neujahrstag".
@sonarqubecloud
Copy link

@arkid15r arkid15r changed the title Switzerland: Jan-01 is called "Neujahr" Update CH holidays: rename Neujahrestag to Neujahrstag Nov 11, 2024
@codecov
Copy link

codecov bot commented Nov 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (a4fcbc7) to head (00cce38).
Report is 3 commits behind head on dev.

Additional details and impacted files
@@            Coverage Diff            @@
##               dev     #2121   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          192       192           
  Lines        11590     11599    +9     
  Branches      1747      1749    +2     
=========================================
+ Hits         11590     11599    +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@arkid15r arkid15r left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for spotting and fixing that @kurtkeller!

Copy link
Collaborator

@KJhellico KJhellico left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@arkid15r arkid15r added this pull request to the merge queue Nov 11, 2024
Merged via the queue into vacanza:dev with commit be594a6 Nov 11, 2024
29 checks passed
@KJhellico KJhellico mentioned this pull request Nov 18, 2024
mstuttgart pushed a commit to multidadosti-erp/python-holidays that referenced this pull request Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants