Visit history file Content Format
Visit history File: contains the data to power Visit history Feature (in short this file contains the timestamps of when you visited particular note).
Visit history file path contains the note id in the file name. Therefore, we do NOT need to duplicate the note id in the events that we store.
The contents of the visit history file are in compact text format with the following structure per line:
Line Structure (VisitPair format)
<FOCUS_TIMESTAMP_MILLIS>:<DURATION_MILLIS>
- FOCUS_TIMESTAMP_MILLIS: When the FOCUS - Visit Event event occurred (milliseconds since epoch).
- DURATION_MILLIS: How long the visit lasted (milliseconds).
Each line represents a complete visit (a FOCUS followed by UNFOCUS).
Example content
1753911954503:4597
1753912000000:60000
This translates to:
1753911954503:4597: Visit started at timestamp [1753911954503], lasted [4597] ms (~4.6 seconds)1753912000000:60000: Visit started at timestamp [1753912000000], lasted [60000] ms (1 minute)
Stored transparently
Per Transparent Data Model, we use a human-readable format to store data in a transparent (non-proprietary) way. We opted away from JSONL to keep files compact while retaining human readability and ease of parsing, so you can see what is being recorded and parse it if you desire.
Future-proof parsing guidance
Future-proof parsing guidance
If you're parsing this data, you can future-proof your implementation by expecting additional fields to be added after the current ones, separated by the : delimiter.
In future versions, we may extend the data recorded per visit:
1753911954503:4597:<some-new-data>:<additional-field>
Simple future-proofing strategy:
- Take one line
- Split on
:delimiter to get tokens - Read
tokens[0](focus timestamp) andtokens[1](duration) - Ignore any additional tokens beyond index 1
This ensures your parser continues working even as new fields are added.
Backlinks