Seems like official export [0] has tags and annotations along with timestamps. However in case you'd like more structured full data from the API (instead of a mess with csv + json?), you can use my tool [1] to export it. Here's example of its output [2]
datetime handling can absolutely be a hot spot, especially if you're parsing or formatting them. Even for relatively simple things like "parse a huge csv file with dates into dataclasses".
Not saying it's necessarily justified in case of this library, but if they want to compete with stdlib datetime in terms of performance, some parts will need to be compiled.
I argued that point in my article some time ago https://beepb00p.xyz/configs-suck.html
also HN discussion at the time news.ycombinator.com/item?id=22787332
I was annoyed by cron/fcron limitations and figured systemd is the way go because of its flexibility and power, but also was annoyed about manually managing tons of unit files. So I wrote a tool with a config that looks kinda like a crontab, but uses systemd (or launchd on mac) behind the scenes: https://github.com/karlicoss/dron#what-does-it-do
But also it's possible to add more properties, e.g. arbirary systemd properties, or custom notification backends (e.g. telegram message or desktop notification)
Since it's python, I can reuse variables, use for loops, import jobs from other files (e.g. if there are shared jobs between machines), and check if it's valid with mypy.
Been using this for years now, and very happy, one of the most useful tools I wrote.
It's a bit undocumented and messy but if you are interested in trying it out, just let me know, I'm happy to help :)
Another thing I noticed is that homebrew python was noticeably slower on M2 comparing to the pyenv one. I imagine homebrew compiles it with too generic flags to support wide range of macs.
A comment in Homebrew's formula says that Homebrew adds the --enable-optimizations flag during compilation because Homebrew has separate binaries whereas the official Python release doesn't add this flag because "they want one build that will work across many macOS releases"
FWIW, never happened to me with Synching, but either way it's best to separate sync software and backup software. Sync might work flawlessly, but the user might make a mistake which would quickly wipe the files across all devices.
I use borg for backups, highly recommend
I sync about two hundred thousands of files without any problems, especially if your aren't changing them all the time. The only issue I can imagine is initial sync with so many files might take a while, even if total size isn't huge.
As for several terabytes, for me it's a bit less than a terabyte in total for all synced folders, but also can't see why it wouldn't scale up. I guess similar, initial hashing might take some time, but otherwise it should handle it well.
not sure what happens if you commit on two devices before syncing, but the "worst" that happened to me is I get an index conflict, in which case it's easily fixed by 'git reset'
[0] https://getpocket.com/export
[1] https://github.com/karlicoss/pockexport?tab=readme-ov-file#s...
[2] https://github.com/karlicoss/pockexport/blob/master/example-...