Zettelkasten MCP Files

What's Changed

• Pseudo-nanosecond ISO 8601 Timestamp Resolution by @diggy in https://github.com/entanglr/zettelkasten-mcp/pull/18
• 2025-04-25_diggy_bump-version-to-v1.2.1 by @diggy in https://github.com/entanglr/zettelkasten-mcp/pull/19

Full Changelog: https://github.com/entanglr/zettelkasten-mcp/compare/v1.2.0...v1.2.1

Issues Identified

The report (#17) correctly highlights some concerns:

• Different precision across platforms:
• Linux: ~84ns resolution
• Windows: ~318μs resolution (3.5 orders of magnitude difference)
• Potential for duplicate IDs: On Windows, if notes are created rapidly (within the same 318μs), they could receive identical IDs.

Implemented solution

• Maintains chronological ordering: Primary sort is still by timestamp
• Guarantees uniqueness: Even for notes created within the same microsecond
• Works across platforms: Not dependent on OS timer resolution differences
• Thread-safe: Uses a lock to prevent race conditions in multi-threaded contexts
• Human-readable: Still follows ISO 8601 format with the counter as a suffix
• Simple implementation: No complex calculations or dependencies

This solution addresses the limitations of time.time_ns() on Windows while preserving the chronological nature of IDs that's so important for a Zettelkasten system. The 3-digit counter allows up to 1,000 notes to be created within the same microsecond, which should be more than sufficient even in high-concurrency scenarios.

This would effectively provide nanosecond-level uniqueness, though with an important technical distinction:

Microseconds + Counter vs. True Nanoseconds

Mathematical equivalence:

• 1 microsecond = 1,000 nanoseconds
• Our approach: microsecond timestamp (10^-6 seconds) + 3-digit counter (0-999)

This divides each microsecond into 1,000 parts, which is exactly the definition of nanosecond granularity

Format equivalence:

• Original: YYYYMMDDTHHMMSSsssssssss (9 digits of nanoseconds)
• Proposed: YYYYMMDDTHHMMSSssssssccc (6 digits of microseconds + 3 digits of counter)

Both have the same string length and sorting characteristics

Conceptual difference:

• Original approach: attempts to measure actual time at nanosecond precision
• New approach: guarantees uniqueness at nanosecond granularity without claiming to measure actual time at that precision

Practical Implications

In the context of our Zettelkasten system, this solution gives us:

• The same level of uniqueness (one in a billion per second)
• Better cross-platform consistency (not dependent on OS timer resolution)
• More reliable operation on Windows systems
• Identical ID format and length
• The chronological ordering important for Zettelkasten methodology

The counter approach is actually superior for our use case because it guarantees that even on systems with poor timer resolution, we'll never generate duplicate IDs, while still maintaining the ISO 8601 timestamp format that makes the IDs human-readable and chronologically sortable.