This looks neat. I wish it used iso8601 [0] dates. It’s pretty convenient as the time periods uses the format YYYY-MM-DD/YYYY-MM-DD and I think is easier to mentally parse than MM/DD/YYYY-MM/DD/YYYY.
Of course I didn’t even know what a solidus (“/“) was until using iso8601.
Also, I usually find standards pretty much as overhead, but 8601 seems pretty good as a universal standard.
As someone who grew up in the US, it's still bizarre as a programmer to have a mixed-significance ordering (MM-DD-YYYY) instead of any consistently-endian ordering (DD-MM-YYYY or YYYY-MM-DD).
Out of curiosity, in what order do Europeans verbally say full dates with month names? Or does it vary by language?
Important note: while a datestamp like YYYY-MM-DD does sort correctly, a datetime stamp such as YYYY-MM-DDThh-mm-ss does not because of DST and negative leap seconds.
Germanic (Dutch, German, Danish, Swedish, Norwegian) languages just say "10 october", they'd never say "October 10th". Before we get our 'english is so stupid!!!' hat on, in many of these (e.g. Dutch and German), the number '87' is pronounced 'seven-and-eighty' ('zevenentachtig' - 'zeven en tachtig' - seven and eighty), which is stupid. Languages are weird).
Same for the romance ones: It's just "Quatorze juillet" - 14th of July (Bastille day).
English is the weird one, but not that weird, "7th of october" is not much more complicated to say than "October 7th".
French is actually not so weird if you think about what a "score" is in English. Gettysburg address literally begins with "four score and seven years ago", which equals to 87.
I really hate watching historical documentaries where they spell out dates with day->month->year. If the intention is to teach, then the year is most important number and all other information is to be catalogued in context of broadest time period. The DD-MM-YYYY forces viewers to keep the whole date in their heads before it can be parsed and understood.
The "Algorithms to Live By" book has a good name for this: computational kindness. We should strive to reduce cognitive burden. The bigger the audience, the more effort should go into making data digestible. Unfortunately the established date standard goes against it.
The other problem is mixing endianness: the date information uses little endian, while numbers themselves are spelled out in big endian. The American MM-DD-YYYY on the other hand... I don't know what they were thinking.
Interesting thing I learned about historical battles: the most important part of the date is the season. In my country there were no battles during winter, early spring and late autumn, most were from April to September. It does not mean month is more important than year.
In portuguese people say "vinte de junho de dois mil e vinte dois", meaning "twenty of june of two thousand twenty two". The first few days of the month are ordinal: people say "primeiro de janeiro" meaning "first of january".
Japanese uses a neat system akin to YYYY-MM-DD. 2022-06-20 becomes ２０２１年６月２０日 meaning "2021 year 6 month 20 day". Really nice to read. Actual pronunciation is very irregular though, especially days of the month where about half of them are irregular.
In Sweden we say 20th June, 2022 and we even use a "DD/MM -YY" shorthand when signing documents for instance, although YYYY-MM-DD is also common and "the more correct".
I moved to the US from the UK a little over 10 years ago.
The numeric month and day of my birthday happen to be the same. For this anecdote lets assume it’s 01/01/1970.
When medical staff ask me for my date of birth, I’ll say “1st Jan 1970”. They’ll reply asking “Sorry, Jan 1st?” And I’ll say “yeah”. This blew my (programmer) mind.
Over the years I’ve rewired my brain to say “Jan 1st 1970” and avoid the extra round trip.
At first I wondered if it had something to do with word order in English, but it sounds like other English speaking countries don’t follow this pattern.
US English has several grammatical and pronunciation characteristics that were common in UK English about 300 years ago. Including being largely (but not totally) rhotic.
The one difference by language is the day: some languages say 1st or 7th, some just 1 or 7. In mine, except for 1st we use the day number, full reading is "day month, year" where the comma is a small extra space.
I’ve been working on markwhen as a way to easily create timelines just from text.
I’ve used it personally to help plan and coordinate my own wedding (https://markwhen.com/rob/wedding) and for keeping track of life events, and I’ve seen it used for event planning, project management, and to visualize historical events or periods of time.
I personally like tools that let you immediately start using them, and I set out to do that here with markwhen.
This is awesome! I want to see other tools like this. I dream of a project management system that is text based and lives in your codebase seems we are pretty close with this. Planning (this), comments / descriptions (markdown), identity / people (??), tickets (??) Anyone know of something like this?
While the Gantt in Mermaid is decent, this would be far, far superior as a bidirectional plugin (i.e capable of both visualisation and editing the original markdown).
This is an excellent landing page that immediately draws my attention and shows why I'd want to use this. This is a great example of how a landing page can demonstrate a tool quickly.
Anyone ever run across anything like this with a simple syntax that can do a timeline with split AND merges? I've always wanted something like the linux timeline [1] as an interactive timeline that can both split and merge.
I'm working on an MIT-licensed time-tracking tool in my spare time and I'm hoping somebody (in a "this is not legal advice"-capacity at least) can enlighten me on licensing here:
If I am understanding the AGPL-3.0 correctly (and assuming that the format is also under the license), I could NOT add an "export to Markwhen" feature to my project without then being forced to convert it to AGPL-3.0.
Is this correct?
For all those who are requesting ISO8601 dates -- according to the GitHub repo [0] these are already supported:
> Dates: A date can be expressed in a few forms. Human readable dates are supported, like 1665, 03/2222, or 09/11/2001, as well as IO8601 dates, like 2031-11-19T01:35:10Z.
Seconding this. I'd love to use this tool, but ideally I want to be editing in the text editor/IDE of my choice and then to be able to own the viewer offline. This would be especially important for actual project management as employers/clients don't tend to allow you to use online tools and that's what I'd most likely be using this for.
Very interesting. Why is there work inside of the education sections of the life timeline? In the project planning example, I could see it being useful to have something like $ref references from Swagger to e.g. reference a duration from a project group into the overall section.
Exporting to pdf/png does a good job of getting everything into view. Otherwise the 'doc' view (the third view option button in the bottom left corner) might be your best bet, it just displays a list
As mentioned in a Github issue, would love to store the Markdown file in my code repository (roadmap) and the markwhen server to deploy hosting the file to my static domain when I deploy my code.
Other than that, you are making amazing progress! And fast also.
Crazy, I just had this idea last week. Although I was imagining a “mermaid for roadmaps”, so closely related but not exactly the same. This looks really cool though!
So cheeaun here posted his life timeline project[0] 9 years ago (!) to hacker news[1] and I always thought it was pretty neat. I made a tool to make timelines like that and it has since evolved into markwhen.
Yes, very awesome what you did with it! Really promising to use as a developer. Always hated all the roadmapping tools that required to generate the roadmap in the tool itself instead of Roadmap-as-Code.
Of course I didn’t even know what a solidus (“/“) was until using iso8601.
Also, I usually find standards pretty much as overhead, but 8601 seems pretty good as a universal standard.
[0] https://en.wikipedia.org/wiki/ISO_8601