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 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?
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".
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.
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.
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.
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.
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 2021年6月20日 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.
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.
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.
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.
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.
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).
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.
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?
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
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.
92 comments
[ 2.6 ms ] story [ 169 ms ] threadI’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.
Let me know if you have any questions!
Did you build the timeline UI yourself? Can it be used as a library?
[0]: https://github.com/mholt/timeliner
[1]: https://twitter.com/timelinize
https://github.com/kochrt/markwhen/blob/main/LICENSE
> kochrt/markwhen is licensed under the GNU Affero General Public License v3.0
The upstream repo that the live site uses is available to sponsors.
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
`2022-08-02T23:00:00.000Z - 2022-08-03T00:00:00.000Z: Event`
but in general I do need to figure out a way to allow more customizable date parsing.[0]
[0]https://github.com/kochrt/markwhen/issues/27
Especially for those outside the USA!
Out of curiosity, in what order do Europeans verbally say full dates with month names? Or does it vary by language?
Same in German.
In Polish, it’s the same, except for official matters since 2002, which now follows ISO8601.
Even in the UK they commonly say the 5th of May, and not May, the 5th (but it does happen).
I can’t talk about other languages.
The only time I see this is in the UK is on movie posters/trailer, e.g. "In cinemas May 5th", which I assume is due to re-using the US material.
PS: 5th of May is a degenerate example, since it's 05/05 regardless of ordering
PPS: 5th of May is also my birthday ;)
When a date is within the current year I state it as for example “27th of June”.
If weekday matters, and specific date is still relevant I’ll say for example “Monday 27th of June”.
I might also simply say “Sunday last week”, “Monday next week”, “Monday at the end of next month”, etc.
Likewise I might say “a couple of weeks ago”, “last week”, “a few days ago”, “in under two weeks”, etc.
Depends on context.
When including a date in a file name I prefer YYYY-MM-DD for date.
When using dates in a directory hierarchy I’ll have years on the top level, with months within them and dates within those.
Sometimes I might use a format like YYYY-mm-ddTHHMMz_s in a file name. For example “something_2022-06-20T1722+0000_1655745728_more_text.tbz”
I much prefer YYYY-MM-DD for its sorting behavior.
And ofc, the mixed order is the inferior option.
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 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.
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 in France: four twenties seven
French in Switzerland: eighty seven (octante sept)
Japanese uses a neat system akin to YYYY-MM-DD. 2022-06-20 becomes 2021年6月20日 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.
I am from India and I say "21st of June 2022"
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.
'June twenty-second' ordering verbally is as distanctly American (not to say you don't hear it, as with many Americanizms) as it is in writing.
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.
[0] https://github.com/cheeaun/life [1] https://news.ycombinator.com/item?id=6833565
Don’t be afraid to distinguish your tool from its inspirations.
https://mermaid-js.github.io/mermaid/#/gantt
I'd happily pay for this as an Obsidian plugin.
https://github.com/kochrt/markwhen/issues/32
Ideally this would be an emacs package.
Once nice thing about Mermaid is it's built into [GitHub's markdown](https://github.blog/2022-02-14-include-diagrams-markdown-fil...) and has support in Notion
[1]https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Di...
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?
I'd be interested to see what you're working on!
https://github.com/kochrt/markwhen/issues/35
Awesome project. Thanks for sharing.
And diffing to know what changed on git etc.