![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
So ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
library_lynn was telling me about how her work schedule goes. As some of you already know she gets alternate Fridays or Saturdays off -- one week she'll work Friday, the next on Saturday, and so forth. Same for most of her cow-orkers; they refer to the two possible schedules as the "A" and the "B" groups.
And every year they take a master calendar, write A, B, A, B, A... on all the Saturdays and post it in a common area, and eventually they transfer the info to their personal calendars so they can figure out if they get a particular Saturday off or not, or whether they need to trade shifts with someone to go to a convention. (Or whatever it is they want to do on a particular weekend; I suppose some of them don't go to cons.) She asked me whether the Thanksgiving weekend would always be an "A" or a "B" weekend. I said no, because I know enough about calendar cycles to answer that, but I couldn't give her a more specific answer.
As many of you already realize, I know a little bit about programming computers and making simple web pages...
So last night after talking to her about this, I looked up the source code to Unix's good old utility "Cal" and hacked it a bit, then built a simple HTML-generating front-end for it. The results are on my server.
And it turns out the answer to the Thanksgiving question is, it changes every 5-6 years. It'll go A, A, A, A, A then B, B, B, B, B. And this explains why it seems like a particular shift "never" gets Thanksgiving's Saturday off -- it's because it stays with one shift for so many years running (which could easily exceed the typical employee's tenure at the place).
The reason it does this is because Thanskgiving weekends are 52 weeks apart, but years are 52 weeks plus a day or two long; eventually the extra days add up to a 53rd week.
P.S. The guys at Bell Labs who wrote the original Cal about 20 years ago were true geeks. The program even handles the Julian/Gregorian calendar changeover in 1752. What's that all about? Under the Julian calendar, all years that were multiples of 4 were leap years; under Pope Gregory's reformed version that we use today, years that are multiples of 100 but not 400 are not leap years. In other words, 1800 and 1900 were not leap years but 1600 and 2000 was; 1500 and 1700 were leap years because they were using the old system.
The reason for the change is because over the centuries the year was slipping in relation to its alignment to the equinoxes and solstices. When they made the switch, they had a shortened year to compensate: in 1752, one of the months was only 14 days long, in order to catch up.
(English-speaking and most western european countries switched over in 1752. The rest of the world took varying lengths of time to catch up. This switch-over, by the way, is why the Russian Orthodox Chuch celebrates Christmas later than December 25 -- they're celebrating it on what would have been December 25 if those 16 days hadn't been skipped. Note that any country that waited until after 1800 to switch would have a 17th day to compensate for, because 1800 wasn't supposed to be a leap year under the Gregorian system.)
The change was controversial at the time, primarily because of people like landlords and such charging for a full month for that 14-day month (while their tenants only had two weeks of wages to pay for that month).
Anyhow, 'cal' compensates for the change in 1752, and correctly displays pre-1752 century years. Calendar geeks...
P.P.S. A lot of people won't care about the A/B effect but want a quick-and-easy calendar, so I added an option to toggle on/off the A/B feature. Also you can print in black and white (handy if you find the color links distracting, or your printer's out of ink), and the source code for the Perl script and the C code are available off of links at the very bottom.
library_lynn was telling me about how her work schedule goes. As some of you already know she gets alternate Fridays or Saturdays off -- one week she'll work Friday, the next on Saturday, and so forth. Same for most of her cow-orkers; they refer to the two possible schedules as the "A" and the "B" groups.And every year they take a master calendar, write A, B, A, B, A... on all the Saturdays and post it in a common area, and eventually they transfer the info to their personal calendars so they can figure out if they get a particular Saturday off or not, or whether they need to trade shifts with someone to go to a convention. (Or whatever it is they want to do on a particular weekend; I suppose some of them don't go to cons.) She asked me whether the Thanksgiving weekend would always be an "A" or a "B" weekend. I said no, because I know enough about calendar cycles to answer that, but I couldn't give her a more specific answer.
As many of you already realize, I know a little bit about programming computers and making simple web pages...
So last night after talking to her about this, I looked up the source code to Unix's good old utility "Cal" and hacked it a bit, then built a simple HTML-generating front-end for it. The results are on my server.
And it turns out the answer to the Thanksgiving question is, it changes every 5-6 years. It'll go A, A, A, A, A then B, B, B, B, B. And this explains why it seems like a particular shift "never" gets Thanksgiving's Saturday off -- it's because it stays with one shift for so many years running (which could easily exceed the typical employee's tenure at the place).
The reason it does this is because Thanskgiving weekends are 52 weeks apart, but years are 52 weeks plus a day or two long; eventually the extra days add up to a 53rd week.
P.S. The guys at Bell Labs who wrote the original Cal about 20 years ago were true geeks. The program even handles the Julian/Gregorian calendar changeover in 1752. What's that all about? Under the Julian calendar, all years that were multiples of 4 were leap years; under Pope Gregory's reformed version that we use today, years that are multiples of 100 but not 400 are not leap years. In other words, 1800 and 1900 were not leap years but 1600 and 2000 was; 1500 and 1700 were leap years because they were using the old system.
The reason for the change is because over the centuries the year was slipping in relation to its alignment to the equinoxes and solstices. When they made the switch, they had a shortened year to compensate: in 1752, one of the months was only 14 days long, in order to catch up.
(English-speaking and most western european countries switched over in 1752. The rest of the world took varying lengths of time to catch up. This switch-over, by the way, is why the Russian Orthodox Chuch celebrates Christmas later than December 25 -- they're celebrating it on what would have been December 25 if those 16 days hadn't been skipped. Note that any country that waited until after 1800 to switch would have a 17th day to compensate for, because 1800 wasn't supposed to be a leap year under the Gregorian system.)
The change was controversial at the time, primarily because of people like landlords and such charging for a full month for that 14-day month (while their tenants only had two weeks of wages to pay for that month).
Anyhow, 'cal' compensates for the change in 1752, and correctly displays pre-1752 century years. Calendar geeks...
P.P.S. A lot of people won't care about the A/B effect but want a quick-and-easy calendar, so I added an option to toggle on/off the A/B feature. Also you can print in black and white (handy if you find the color links distracting, or your printer's out of ink), and the source code for the Perl script and the C code are available off of links at the very bottom.
