-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Week Numbering #32
Comments
Looking back at the part description:
I don't think these can actually correspond to any of the four week numbering schemes I mentioned in the PR as those use either the range |
Personally I think all this is tedious and I would advise people to not use such numbers, but if they must then these are the definitions I would suggest:
The above can be used together with the normal
See also: |
I agree it's a bit tedious. I consider CalVer more descriptive than an enforceable standard. Note the note in that section which specifies that projects claiming to be CalVer need to state any unconventional calendar choices. (Still waiting for the day I do a Jalali CalVer project). I'm not even sure using ISO as the default helps:
Hardly intuitive, that seems like that's going to need explanation for most audiences regardless. So I'm not sure if all the notation is necessary. We always have the option of letting the maintainer specify what's meant by "week". They know their audience best. We can add a note that says week segments should be used with caution, because there are so many definitions, but when in use the range won't exceed 00-54, and that it's up to maintainers to specify the semantics further. |
Oh wow, I didn't know about 54 week years. So much fun! Rather than go back and forth on PR #31, should I close and let you (re)write yourself. Since PyCalVer will be generate week numbers, I'll have to decide on some definition. I think I'll go forward with the above parts, since they're easy to implement with |
This relates to PR #31
Looking into this further, it appears that (at least for python)
strftime
actually goes from 0-52 and not 1-53 and the weeks are not actually always 7 days long:This has the benefit of avoiding the third issue I mentioned in the PR.
Even with the current ambiguity of
WW
/0W
, they have an impact onhow to interpret the
YYYY
/YY
/0Y
which is not explicitly stated.The text was updated successfully, but these errors were encountered: