So that seems like they're doing some kind of math using the week of year in the calculation- but for what purpose? The UI doesn't seem to give you any options for day of week, just time of day.
Maybe there's code in there that checks day of week but it's hardcoded to run every day to make the UI simpler.
Speculation: the calendar in the clock app is week oriented. It would make sense to store one-time events as (day of week, week number, year).
January 1 and 2 of 2011 are actually part of week 52 of 2010. So, an event for January 2 2011 would be stored as (7, 52, 2010).
Now all it takes is somewhere else for someone to accidentally use the year of the current date instead of the year of the current week when checking to see if an event is due.
On January 3, which is the first day of the first week of 2011, the year of the date and the year of the week again match, so all us well until January 1 2012. In 2012, the bug will only last for 1 day, as week 1 of 2012 starts on Monday the 2nd.
yeah, calendar manipulation is trickier than it looks. If you use day-of-week, you have an odd number of days. If you use day of month, many months have an odd number. If you use day of year (%j), most years have an odd number.
There's many such examples - every 1, 2, 3, 4, 6 hours works - but every 5 hours doesn't. But every 2 days and every 14 days are requirements I've met IRL.
I think that's a stretch. I like the calendar, but from what I can tell it's only useful for looking up the day of the week that a date falls on; shrinking it like this is similar to lossy compression.
With a moderate amount of practice you can also calculate a weekday given a date in your head! (Though I'd rather use this w)
So this is not exactly a "product"; people wouldn't fork over money for this. It's a neat design concept.
To add: CLIs aren't necessarily clever (I'd add rarely clever), and Windows-like products can often be far from simple. There are learning curves involved, but I think that's (mostly) a separate matter than simplicity/cleverness.
Again I think this calendar is cool, props to OP for thinking outside the box and making something for the new year~
I image that it would be handy in some forms of accounting software. Some countries are very found of using week numbers, pretty much any government employee in Denmark uses week numbers, rather than actual dates, so you end up needing to known which year the current week belongs to, in this case 2015.
I wouldn't be surprised if it was just a for loop checking for all the years in a range, whether they start on the same day of week, and are/are not leap years :)
It makes me wonder how serious this is as a bug. If part of the programming understands leap years, but other parts don't understand the ramifications, it is entirely possible for things to go wonky when dealing with dates such as "The last Saturday of February 2020," or how it'll handle things either on, or scheduled on that day or some time thereafter.
How many days elapse between Friday and Sunday in that week? Depending on what it uses to count, you could get pretty wild answers.
Bonus problem: in my company, the business calendar (which is the first week of the year, quarter ends) is sometimes shifted by one week with respect to the ISO definitions for historic reasons.
I have implemented a large application which does a lot of time calculations, and run onto most of the issues listed in the article, except that I didn't use hewbrew calendars :).
From another point of view, a given date gradually occurring on every day of the week is a feature, not a bug. I see that the proposed calendar puts my birthday on a weekend, every year year after year, but I kind of like my birthday (and my wedding anniversary, and other important dates) occurring on a new day of the week each year, for variety.
I note too that the calendar would not "make it easy to plan annual activities" for any of the dates in the "extra week" proposed for the calendar, if by annual activities we mean activities that occur in every calendar year. The extra week occurs "at the end of December every five or six years," and the new memory load everyone would have to bear is remembering which years--2015, 2020, 2026, 2032, 2037, 2043, 2048, 2054, 2060, 2065, 2071, 2076, 2082, 2088, 2093, 2099, 2105, "et cetera" are the extra week years.
This makes perfect sense if your role is in bookkeeping / accounting / finance. Your life is based on pay periods and not on day-of-year/month. A particular pay day "belonging" to a particular year is a meaningless affectation: people need to get paid every two weeks come hell or high water, and anything that can complicate the smooth running of that process is discarded.
As for the algorithm:
> The ISO 8601 definition for week 01 is the week with the first Thursday of the Gregorian year (i.e. of January) in it. The following definitions based on properties of this week are mutually equivalent, since the ISO week starts with Monday: […]
I've been using an independent calendar for my own records for over a decade now - it's the day-of-year, written base 7. It fits in with weeks; if we reset weeks every year (why not? we do worse things already with leap days and seconds) then dates become equivalent with weekdays. One number expresses the day-of-year, day-of-week, week-of-year, and month-of-year, using a 49-day month.
I don't really expect many other people to use this, despite being a better designed system. I think hardcore math/cs people would like it, though. I've written some small pieces of code that work with this system, if anyone's interested.
So we only have four months (seasons) and each has nine weeks of ten days each. Each season starts with a neutral day (equinox and solstice) then follow the weeks with ten days each. At the end of the year there is a universal holiday and an extra holiday for leap year.
We could also name all days of the week after the eight planets and the sun as initially intended (including moonday). We could have seven working days and three days off or three working days then two off then three more working days then two off per week.
Whatever, just wanted to leave a stinky brainfart in this room for posterity.
So all the hard work of converting year/month/day to InternalTicks is done at creation time, greatly simplifying the weekday calculation occurring later.
I hear this is a firmware bug, and should automatically sort itself out once we hit March (but there is a bugfixed f/w due too). My pet theory/guess was that there was a misimplementation of some algorithm like Zeller's congruence (https://en.m.wikipedia.org/wiki/Zeller%27s_congruence) for calculating the day of the week, which works on an adjusted year starting in March, because I couldn't come up with any other reason why a leap year bug would manifest for all days before feb 29 and then not thereafter. But there is probably a duller explanation :-)
This sort of reminds me of this neat day-looker-upper: https://imgur.com/KKipvmV . To find the day of the week of Month-Date, just find their intersection in the table. Afaik this is the most compact representation of a year's calendar possible.
You do need a new one each year, but there are only fourteen distinct possibilities (7 days that Jan 1 can be, times 2 choices of leap year or not). Figuring out the equivalence classes of years is a fun problem.
Maybe there's code in there that checks day of week but it's hardcoded to run every day to make the UI simpler.
reply