Issues with metadata on markdown export

[johnrengelman]

Noticing a few issues with the new md command.

Missing Year in markdown file name

The file name includes a post date, but it's only the month and year, which interleaves multiple years together

Unfriendly date encoding in file name

The file name is including a date encoded in readable text instead of ISO format
Sat\ Mar\ 07-karpathy-i-packaged-up-the-autoresearch-project-into-a-ne.md

Incorrect metadata

The above tweet is metadata that cannot be possible. Specifically the bookmarked_at date is before the posted_at date -

---
author: "@karpathy"
author_name: "Andrej Karpathy"
posted_at: Sat Mar 07
bookmarked_at: 2024-11-20
category: tool
domain: ai
categories: [tool, research]
domains: [ai]
source_url: https://x.com/karpathy/status/2030371219518931079
tweet_id: "2030371219518931079"
likes: 28298
reposts: 3646
---

This looks like a deeper issuer before the ft show <id> --json command also has incorrect data -

{
  "id": "2030371219518931079",
  "tweetId": "2030371219518931079",
  "url": "https://x.com/karpathy/status/2030371219518931079",
  "text": "I packaged up the \"autoresearch\" project into a new self-contained minimal repo if people would like to play over the weekend. It's basically nanochat LLM training core stripped down to a single-GPU, one file version of ~630 lines of code, then:\n\n- the human iterates on the https://t.co/3tyOq2P9c6",
  "authorHandle": "karpathy",
  "authorName": "Andrej Karpathy",
  "authorProfileImageUrl": "https://pbs.twimg.com/profile_images/1296667294148382721/9Pr6XrPB_normal.jpg",
  "postedAt": "Sat Mar 07 19:53:15 +0000 2026",
  "bookmarkedAt": "2024-11-20T08:07:48.007Z",
  "categories": [
    "tool",
    "research"
  ],
  "primaryCategory": "tool",
  "domains": [
    "ai"
  ],
  "primaryDomain": "ai",
  "githubUrls": [],
  "links": [],
  "mediaCount": 1,
  "linkCount": 0,
  "likeCount": 28298,
  "repostCount": 3646,
  "replyCount": 1060,
  "quoteCount": 1109,
  "bookmarkCount": 39250,
  "viewCount": null
}

md command should provide way of configuring output directory

I already have my own LLM Wiki and want to import bookmarks into it - an option to specify the output directory would be helpful so I can send new bookmarks into my triage/enrich/ingest flow.

[afar1]

@johnrengelman — two follow-up PRs have landed on main that should address all three symptoms you reported, and I'd love a confirmation before closing:

1. Filename month-only + unfriendly date encoding (Sat\ Mar\ 07-...) — fixed by PR fix: Format dates as YYYY-MM-DD in ft md exports instead of using raw string slice #63 (fix: Format dates as YYYY-MM-DD in ft md exports instead of using raw string slice, merged 2026-04-09). Filenames should now be 2026-03-07-... format.
2. bookmarked_at before posted_at — likely fixed by PR [codex] Fix GraphQL bookmark dates and fetch-media post assets #72 (Fix GraphQL bookmark dates and fetch-media post assets, merged 2026-04-11), which stopped fabricating bookmark dates from the GraphQL response.

Once v1.3.6 ships you can npm i -g fieldtheory@latest and rerun ft md. If your exports come back correct on all three counts, please drop a confirmation here and I'll close. If any of them still misbehave, let me know which specific ones and I'll reopen scope.

[unsync]

Hello @afar1
i did a full re-sync after deleting the .ft-bookmarks and see the same timestamp issue in v1.3.9:

---
author: "@Thom_Wolf"
author_name: "Thomas Wolf"
posted_at: Fri Apr 04
category: unclassified
source_url: https://x.com/Thom_Wolf/status/1908170645818536087
tweet_id: "1908170645818536087"
likes: 61
reposts: 12
---

[johnrengelman]

I also still see the same file name pattern and old encoding posted_at field -

% ft -V
1.3.9
% ls ~/.ft-bookmarks/md/bookmarks
Fri Apr 03-tom-doerr-obsidian-vault-for-claude-code-memory-https-t-c.md
Fri Apr 10-axel-bitblaze69-some-important-claude-code-security-settings-you-n.md
Fri Apr 10-coreyganim-the-clearest-explanation-of-claude-managed-agents.md
Fri Apr 10-danveloper-https-t-co-n2zjeizky4.md
Fri Apr 10-leopardracer-https-t-co-c4zi0vicnj.md
...

[johnrengelman]

@afar1 looks like #63 was closed, not merged.

[ccage-simp]

That's confusing. I thought he was using the code from #63 in another pr.

[unsync]

I got the same confusion.
There are references to #63 but is closed not merged, pointing to this one as being considered, then first reply #53 (comment) mentioning the #63 as possible fix 😅

Just wanted to bump this one to mention that currently in the v1.3.9 the timestamp issue is still there, and a bit annoying considering posted_at is missing the year :D

[ccage-simp]

Yeah, I can't merge my own PR because I'm not a maintainer and I didn't have an approval anyways. From his comment on this issue, I thought Andrew was going to do like he's done in other PRs and borrow the code from the draft PR that I had created. So I might have too hastily closed the PR that I had open (#63) and caused Andrew to forget to merge that one to fix this issue.

I think part of this is maybe not having clear guidelines as to what the author of this repo prefers as far as collaborations from outside committers. I've tried to guess on that, and it has seemed to be that he prefers we create an issue first, and then maybe a draft PR that addresses the issue to give him an idea. Then it seems that he prefers to build his own PRs using the ideas from issues and outside PRs.

[johnrengelman]

Testing with 1.3.12 -

1. posted_at is accurate
2. filenames have proper ISO encoding
3. bookmarked_at has been removed because it's not a timestamp -

% cat ~/.ft-bookmarks/md/bookmarks/2026-04-19-heynavtoor-claude-can-now-meal-prep-your-entire-week-and-hit.md
---
author: "@heynavtoor"
author_name: "Nav Toor"
posted_at: 2026-04-19
category: unclassified
source_url: https://x.com/heynavtoor/status/2045826159636824423
tweet_id: "2045826159636824423"
likes: 4624
reposts: 362
---

[afar1]

thanks for sticking with this and for confirming the v1.3.12 behavior. closing this out since the current md export path now writes iso filenames / posted_at values and no longer emits the fabricated bookmarked_at timestamp. if this pops back up on a current release, we can reopen.