For the last 3 years I've been printing several copies of the Compact Calendar by David Seah [1]. It's as its name implies a compact form calendar that spans the whole year in a single page, and leaves enough side space to annotate stuff as needed.
It's very cool and useful, although it would be nice having an open-source based version (i.e. LibreOffice), for those of us that don't have an MS Office license...
(not sure why but upon checking the website I'm seeing all text and links scrambled in the page, probably the author inadvertently broke it during an update)
Oh cool! I happened to build something similar a while back, because I was frustrated with the way that the Unix `cal` program laid out all the months in a 3 x 4 grid instead of in a continuous format:
Wow I just discovered that it's uBlock Origin that totally breaks the page layout. Which means that for some reason this page's CSS are detected as an ad source, and blocked! Curious, as it seems to be a plain and simple static site.
It's also blocked by Fanboy's annoyances list. It's a generic blocker, /wp-gdpr, probably designed to block a Wordpress plugin's GDPR banner. My guess is this site is using such a plugin, and then stuck the rest of its CSS in the plugin's folder instead of a generic folder like CSS, so it ends up blocked there too. You can whitelist this URL on the site if you want without having to whitelist the site as a whole.
What do you mean “open source”? XLS is the (previously proprietary) format used by older versions that’s (basically) just serialized structs. XLSX (which I see here) is the ZIP/XML based version based on an open standard[0][1]. LibreOffice opens those just fine from my experience; It’s the older binary format that LibreOffice can screw up with formatting.
Perhaps things have gotten better, but OOXML is not an open format by the normal usage of the word (text based does not mean open). OOXML was rushed through the standardization process, and was entirely created by one vendor (Microsoft).
Microsoft doesn't even bother to support the OOXML format completely, as the Wikipedia article notes.
You are right although as I understood it, the MS standard is exceedingly complicated, some would say in an attempt to "obfuscate" it.
In any case, this specific excel template states that it requires Excel 2007 and might misbehave if using any other program such as OpenOffice or Google Sheets:
> Please note that Microsoft Excel 2007 or newer is required. Other software like Open Office, Google Docs, and Numbers may import the Excel spreadsheet, but due to differences in the way they handle dates you should double-check that the calendars are correct.
I print a bunch of these (sometimes multiple calendars on a page) and stick them up on the wall. Very useful to separate events / agendas of different classes on separate calendars e.g. birthdays, travel plans, project deadlines, appointments, goal tracking, habit tracking all go on different calendars but on the same wall.
Much cleaner than putting them all on the same calendar and fight for space.
It renders fine for me in Firefox, but garbled in Chrome. Disabling this CSS rule "fixes" the layout for me in Chrome, without breaking anything obvious in Firefox:
This reminds me of the Doomsday algorithm¹. The doomsday for 2020 falls on a saturday, which is aligned neatly as the diagonal in the one page calendar. Once you know the doomsday of a given year, you can calculate the day of week for any date in that year in your head.
Here's a probably faster/easier way for most people to compute the Doomsday for a given year.
The Doomsday is the sum of a factor determined by the century part of the year and a factor determined by year within the century.
The century factor is:
Century Factor
20xx 2
21xx 0
22xx 5
23xx 3
This pattern repeats every 4 centuries indefinitely forward, and however far back you can go in your jurisdiction before you hit whatever calendar that was used there before the Gregorian calendar. (If you want a formula for this, it is 2 + (C % 4) x 5, where C is the first two digits of the year, but since there are only 4 items in the pattern, and most people will actually only care about one or two centuries, I'd just memorize the relevant factors).
For the factor determined by the year within the century, let T be the tens digit of that year and U the ones digit.
If T is even, the factor is:
2 x T + U + LE(U)
I'll cover LE below.
If T is odd, the factor is:
2 x T + 3 + U + LO(U)
LO() and LE() are corrections to take into account leap years in years where U != 0. Leap years when U = 0 are already accounted for in the 2 x T. Here are LE() and LO().
LE(U) = 0 if U < 4
LE(U) = 1 if 4 <= U < 8
LE(U) = 2 if 8 <= U
LO(U) = 0 if U < 2
LO(U) = 1 if 2 <= U < 6
LO(U) = 2 if 6 <= U
Or in English, in even decades add 1 if U >= 4, and add another 1 if U >= 8. In odd decades, add 1 if U >= 2, and another 1 if U >= 6.
Example: 2020. Century 20 factor = 2, T=2, U=0. T is even. Doomsday is 2 + 2 x 2 + 0 + 0 = 6 (Saturday).
Here are the years used for some of the examples in the link you gave.
2019. T=1, U=9. We've got an odd T, and a leap year correction of 2. Century is still 20. That gives us 2 + 2 x 1 + 3 + 2 + 2 = 4 (Thursday). I've taken the liberty of reducing mod 7 along the way, so used 2 instead of 9 when adding in U. Note that when figuring the leap year factor you have to use the actual U, not U mod 7.
2018. 2 + 2 + 3 + 1 + 2 = 3 (Wednesday).
2017. 2 + 2 + 3 + 0 + 2 = 2 (Tuesday).
2069. 2 + 2 x 6 + 2 + 2 = 4 (Thursday).
1929. 3 for 19xx. 3 + 2 x 2 + 2 + 2 = 4 (Thursday).
And in fact: Just knowing that the doomsday of 2020 is a saturday, I was able to construct the entire one page calendar with pen and paper in a couple of minutes.
My thought was "Your calendar is bad and you should feel bad." It's a reference and I don't actually mean that, except as a reaction to seeing it after clicking the title on HN which had me expecting something I might want to use.
I am guessing that people outside the US do not have as much trouble, as the format is naturally dd/mm/yyyy instead of mm/dd/yy, so reading left to right is more natural.
It took me a brief moment to acclimate to this, but after I did I felt it was pretty straightforward and elegant.
1. On the left under "Dates" are the consecutive days of the month if you read column by column (of course not every month has 31 days).
2. The rows represent intervals of a week (hence each square is previous + 7).
3. Look first at the top left cell with June and Monday. That lines up with the days of the month 1, 8, 15, 22, 29. That's because those are all the Mondays of June.
4. Next row (same column) shows similar: The Tuesdays of June are 2, 9, 16, etc.
So you can start with any month (the columns) and look at the first row underneath to see which day of the week the month starts on and then follow the dates from there using the above logic.
This is pretty clever and I admire the author for coming up with an elegant way to show the mapping of week days to dates. I'd be particularly interested to see the algorithm behind it. Date computations are very tricky.
A few years ago I made script to generate a one page calendar because the ones they hand out at work are particularly ugly. In addition to showing the date<->weekday mapping I also wanted it to show holidays and pay periods. This is one of the (few) things stuck on my wall.
You can tell that 2020 is a leap year because if you look up the day of the week for Feb. 28, it's Friday, and March 1st is a Sunday. That must mean that Feb. 29th is a Saturday. And indeed it is.
One of them is very similar to this one (Design 2) - I was tidying up someone else's idea. Dunno if David Seah's was related in any way or just people came up with the same idea.
Agreed. I love stacking the months like that and turning it into a never-ending river of days, looks like it'd be easier to estimate the length of time between two different months.
I'd guess the count of a particular month's days could be shown next to its name as an aid? Esp. given that Feb tends to have it different in different years (https://en.wikipedia.org/wiki/Feb_29).
It took me a while, but I think I have it: choose a month of the year in the blue table and read only the column pertaining to that month. The column has seven days within it and the first day in the column matches the first day of that month; then, increment each day and date until reaching the maximum for the month and proceed to the next month in its matching column. Never move right to left in the blue month table as if moving through a standard calendar's format; only loop through the column for the current month from top to bottom.
These upvotes prove that there is opportunity for products to be clever, but not simple. For every windows like product, there is an opportunity for command line tool.
Clever but not simple? I have a hard time believing that people want to sacrifice simplicity for cleverness. But I see your point about people preferring a CLI than a web portal. I guess simplicity is in the eye of the beholder. What's simple for me, can often be wizardry for my dad.
At the risk of facing the wrath of developers, they also choose products that are not are not necessarily clever, but makes them clever. e.g: IaaS Vs PaaS, C++ Vs Visual Basic etc.
Developers usually say that abstraction doesn't give them enough control/flexibility. That might be true in some cases. But in most cases, they are afraid that abstraction will make them dumb, instead of making them clever.
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~
Has anybody noticed that, starting tomorrow, the current day of the week, day of the month and month will be highlighted, with the highlighting changing correctly every day?
It took me stupidly long to work out how to read it, which I think was just because days don't progress in the usual way, i.e. avoided if months were swapped to the rows, and days read across.
Another improvement IMO would be to list e.g. 'June (30)', since at the moment the #days in each month is lost to compression.
Great concept. I would've prefered an option to switch the days of the week and dates of the month. That way the numbers loop and the day of the week is fixed as a row/column header. That's more similar to how we read usual wall calendars.
This is super cool. Since I usually read Month, Date, Year - would've been awesome if the months/day was on the left. Took me a minute to read it - but makes a lot of sense.
To find the current day of the week, look at the row corresponding to the day of the month and the column corresponding to the month. There's a typo for the days 18-21 where there's two 18s.
It's very cool and useful, although it would be nice having an open-source based version (i.e. LibreOffice), for those of us that don't have an MS Office license...
[1]: https://davidseah.com/node/compact-calendar/
(not sure why but upon checking the website I'm seeing all text and links scrambled in the page, probably the author inadvertently broke it during an update)