On Tue, Jun 21, 2016 at 07:58:15PM +0200, Rune Pade wrote:
> On Tue, Jun 21, 2016 at 07:32:15PM +0200, Otto Moerbeek wrote:
> > On Tue, Jun 21, 2016 at 07:03:19PM +0200, Peter N. M. Hansteen wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > >
> > > On 06/21/16 14:43, li...@wrant.com wrote:
> > > > I think Nick is right, the paper economics would mess week order,
> > > > check:
> > > >
> > > > $ cal -w jan 2016
> > > >
> > > > January 2016 Su Mo Tu We Th Fr Sa 1 2 [ 1] 3 4 5 6 7 8 9 [
> > > > 2] 10 11 12 13 14 15 16 [ 3] 17 18 19 20 21 22 23 [ 4] 24 25 26 27
> > > > 28 29 30 [ 5] 31 [ 6]
> > > >
> > > > Jan 31, 2016 does not belong in the first week, it is in week
> > > > number [6].
> > >
> > > according to at the conventions the printed calendars here (Norway,
> > > but I suspect the rest of Europe is the same), January 1 and 2 do not
> > > belong in week 1 either. Rather, the convention is that at year end,
> > > if a week is split between two years, that week gets the number
> > > belonging to the year that has the most days of that week.
> > >
> > > Our cal does not follow that convention, that is, while it displays
> > > December of 2015 correctly,
> > >
> > > [Tue Jun 21 18:56:52] peter@elke:~$ cal -w dec 2015
> > > December 2015
> > > Su Mo Tu We Th Fr Sa
> > > 1 2 3 4 5 [49]
> > > 6 7 8 9 10 11 12 [50]
> > > 13 14 15 16 17 18 19 [51]
> > > 20 21 22 23 24 25 26 [52]
> > > 27 28 29 30 31 [53]
> > >
> > > January 2016 comes out wrong (at least according to the convention here)
> > > :
> > >
> > > Tue Jun 21 18:56:59] peter@elke:~$ cal -w jan 2016
> > > January 2016
> > > Su Mo Tu We Th Fr Sa
> > > 1 2 [ 1]
> > > 3 4 5 6 7 8 9 [ 2]
> > > 10 11 12 13 14 15 16 [ 3]
> > > 17 18 19 20 21 22 23 [ 4]
> > > 24 25 26 27 28 29 30 [ 5]
> > > 31 [ 6]
> >
> > Cal uses the ISO numbers (which is what you describe, the first week
> > of a year is the week containing the first Thursday of the year)) if
> > both -m and -w are given:
> >
> > [otto@mini:52]$ cal -wm jan 2016
> > January 2016
> > Mo Tu We Th Fr Sa Su
> > 1 2 3 [53]
> > 4 5 6 7 8 9 10 [ 1]
> > 11 12 13 14 15 16 17 [ 2]
> > 18 19 20 21 22 23 24 [ 3]
> > 25 26 27 28 29 30 31 [ 4]
>
> The interestings question here seems to be why anyone want to see a
> non ISO 8601 compliant week number (https://xkcd.com/1179/)?
>
> The source points to The Calendar FAQ for the isoweek function, but
> there are no hints in the week function as to why or how this
> numbering scheme would be useful.
>
> Rune
I think we kept the original numbering scheme since it was already
there, maybe it is used in the US. But for all practical purposes (at
least in Europe) -wm should get you the expected numbers,
-Otto
> >
> > >
> > >
> > > ncal on a FreeBSD system I have within reach does what I had expected:
> > >
> > > [Tue Jun 21 18:55:02] peter@rosalita:~$ ncal -w jan 2016
> > > January 2016
> > > Mo 4 11 18 25
> > > Tu 5 12 19 26
> > > We 6 13 20 27
> > > Th 7 14 21 28
> > > Fr 1 8 15 22 29
> > > Sa 2 9 16 23 30
> > > Su 3 10 17 24 31
> > > 53 1 2 3 4
> > >
> > > (ncal on Linux does much of the same, but of course the command line
> > > syntax differs slightly)
> > >
> > > I was blissfully unaware of cal -w until you wrote this, and I don't
> > > really care for the diff that started this thread, but having correct
> > > week numbering is to my mind a lot more useful. Then again, there may
> > > be week numbering conventions I'm not aware of (and of course there's
> > > the Monday vs Sunday as week start day issue).
> > >
> > > - - P
> > > - --
> > > Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> > > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> > > "Remember to set the evil bit on all malicious network traffic"
> > > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> > > iQIcBAEBCAAGBQJXaXNUAAoJELJiGF9h4DyejC0P/3P+wqcSTjf2vMDF43GZAThl
> > > /ItGSZ2jHh328SxvHKBzGP7q/2YXWqPgx87T4gc72hgMCISTIuEH0Fnj3EfiDrnA
> > > 1IEvd9yBykcRiA5m8d0n8Wn1be9KO+Lr/5bJUoEFOzeeNy4rctLlcLmBw9+JpJ5l
> > > Ihmo0GKWM9GEcx+XK8ROUhx9t3vzOEwVRqqvgl3E+LdlCHRlbjh8sSaNWSXSI4CZ
> > > 7xbavcuyD16NYF/8t5K2dFq/cy+LX8SeY0MemwwabEQ7mpg5UJ9XAdJxT3f8RYgQ
> > > FJCys5DlYu8ErpipJx+9No6mXwf/ZE5BMo2+5Z3EWK7PwFNut45Zqvqn+ESHa+4r
> > > taElGMkskGQcjuogXtaN0nQfwzkMN0BB1tkn5j1GTqSoBm81AdQxbGTQx2BBV7oR
> > > NeJ7q6PrxNiAPZ8hkmvevYOU8PVE4fqjSwYZlm0vvfKMbMhaQ+w7g8Yx+85886GN
> > > xmNQktlWz2oT8yD5VMN5Rw2+r9JJ74B/Z1ak+ie1oO7rPoG00BZrjIEmHoUtcU7D
> > > djgSPh35iHbkBuxNFbjH6sgQ/R3WcG/qzpQrBdDYssL84pUrL2r7KeY8fDvX04mr
> > > 3BTqimm/Z/YPYkmTnEt9tn3mgPjEzvMGcVBfVvAdv/DwW5VS3gXTfoJ8NxDLVYdF
> > > E/sbtSG/4VihzO8feaG7
> > > =aX5J
> > > -----END PGP SIGNATURE-----
