Hacker News new | past | comments | ask | show | jobs | submit login
Generate Unicode Calendars for Markdown (qwerty.dev)
115 points by nabeards 15 days ago | hide | past | favorite | 24 comments

Being this a Unicode calendar generator, notice that according to the internacional standard ISO 8601 Monday is the first day of the week.


ISO 8601 is not related to Unicode (ISO/IEC 10646), but if you do care about Unicode you may notice that Unicode CLDR actually supports the preferred first day of the week as a part of locale identifiers [1] (e.g. en-US-u-fw-mon will make the first day of the week Monday, as opposed to the default Sunday for USA).

[1] https://www.unicode.org/reports/tr35/#UnicodeFirstDayIdentif...

The definition of Monday as the first day of the week is strictly for the sake of week numbering over the course of the year and does not indicate that a calendar which displays weeks starting with Sunday violates the ISO standard.

Yep, making Sunday the zero'th day.

:) Nice try, but I'm afraid none of the data elements related to dates are zero-indexed (ie month 0, week 0, year 0, etc)


update: technically year 0 in ISO 8601 corresponds to year 1 BC

> :) Nice try, but I'm afraid none of the data elements related to dates are zero-indexed (ie month 0, week 0, year 0, etc)

If you ask POSIX, or any date/time API that slavishly copies POSIX (say, java.util.Date or JavaScript's Date object), January is month 0.

This comment made my day. :-)

This is a lovely little project but it makes no claims to be for markdown—the site makes no mention of it as far as I can see. And, of course these fun unicode calendars don't render in Markdown.

Can we change the title back to "Unicode Calendar Generator"?

Not only that, the copy to clipboard function produces text that DOES NOT render correctly when pasted into a Markdown doc.

Interesting, it renders properly for me. I paste it in surrounded by the triple backtick.

You don't put Markdown surrounded by triple backticks though... That's for code or other text that is not Markdown.

With Pandoc's Simple Table format[1] it's as simple as (plain ASCII):

    : October       2021

    Su Mo Tu We Th Fr Sa 
    -- -- -- -- -- -- --
                   01 02 
    03 04 05 06 07 08 09
    10 11 12 13 14 15 16
    17 18 19 20 21 22 23
    24 25 26 27 28 29 30
the only caveat being, that "October 2021" is implemented as caption and thus will become centered.

And then:

    pandoc -f markdown -t html -o ./pandoc-table.html ./pandoc-table.md
[1]: https://pandoc.org/MANUAL.html#tables

Now if cal(1) could produce this, that would be even more awesome. Currently it does this by default:

        Oktober 2021
    So Mo Di Mi Do Fr Sa
                    1  2
     3  4  5  6  7  8  9
    10 11 12 13 14 15 16
    17 18 19 20 21 22 23
    24 25 26 27 28 29 30

On Firefox for android they don't render that great, the first row is misaligned and the day indicator is all over the place.

Try the rounded corners, looks nice:

    │ October       2021 │

TIL about unicode rounded corners.

Thanks @mixmastamyk, you just inspired me to add support for them into the python-tabulate project: https://github.com/astanin/python-tabulate/pull/151

There is a bug. October has 31 days, but the generated calendar have 30 days. Since the website doesn't seems to be open source, I cant fix it.

And February 2021 only had 27 days, apparently... hmm.

This has nothing to do with Markdown. Was that word included for SEO or something? Perhaps a better title would be "ASCII Art Calendars".

"markdown" is not to be found on the page, so it's not for SEO; the submitter (incorrectly) editorialized the title. It's also not restricted to ASCII, so your suggestion does not increase title accuracy.

Apologies, it was sent to me as a Markdown-compatible calendar generator. Didn’t mean to editorialize the title.

Is the lib to generate those opensource? Would love to try it

heh. If you overflow the date past the past about year +/- 250000 you break the website and it has to be reloaded (in Firefox at least)

October 31 is easier.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact