Closed longguzzz closed 6 months ago
Thanks for taking the time to do this pull request, but I fail to see the value.
I assume you are seeing the "time deviation" in the drop down of versions. Any "time deviation" there is probably due to:
At any rate, I don't think it's a problem that needs fixing (especially given DOS date precision of zip contents).
Thanks for your remind, you are right. My Math.floor(file.stat.mtime / this.msOfEditSamplingPeriod) <= Math.floor(zipFile.stat.mtime / this.msOfEditSamplingPeriod)
way can only effect in a statistical sense and can not eliminate single time deviation caused by DOS date precision.
FYI I created https://github.com/antoniotejada/obsidian-edit-history/issues/15 to implement changing the zip file date to match the last version file date which should help preventing time drift.
FYI I created #15 to implement changing the zip file date to match the last version file date which should help preventing time drift.
Thank you. However, after giving it some more thought, I've come to believe that the functionality for behavioral statistics and tracking should be implemented independently from the version history recording feature. This is because if the timing information used for statistics is strongly bound to the complete text of the file, the space consumed could end up being tens of times that of the original note after a long period of statistics gathering. To save space, we would eventually be forced to discard older historical statistical information. Therefore, for tracking and statistics, I will look for other solutions for statistics. Your code is a very good example for how to detect Obsidian events and track edit behaviors. Thank you very much!
No problem, whatever works for your use case.
Having said that,
That obsidian-edit-history is good at detecting edit behavior leads to my idea about statistics. So, I tried to figure out whether the time information can be used for statistics. That's why this PR created. And the time deviation "problem" only occurs when someone trys to use it for recording high-frequency editing behavior.
In my opinion, the drift is mainly from (file.stat.mtime - zipFile.stat.mtime) < this.minMsBetweenEdits
. The minMsBetweenEdits
is lower bound of next stored edit time. There is always a time gap between the last_modified_time + minMsBetweenEdits
moment and next first valid detected edit. accumulates. And it accumulates. Therefore, sampling can not avoid the time deviation.
However, I believe my use case is rare. (So I decide to find other way to do statistics.) Most people use this plugin mainly for normal backup. So, actually there is no problem for obsidian-edit-history.
I add a new way to limit edit store with a given time in periods. It can prevent the accumulation of time deviation.
eg. store time with
inSecondsBetweenEdits
setted as 60 when continuously editing: 12:00:50, 12:01:53, 12:02:54, 12:03:57, 12:05:00 store time withsecondsOfEditSamplingPeriod
setted as 60 when continuously editing: 12:00:50, 12:01:01, 12:02:03, 12:03:02, 12:04:01, 12:05:03It is useful when using time data in
.edtz
file for statistics, especially for a short interval, eg. 20s