Class Templates + Timestamp = Weird behavior

This is an interesting bug and it’s taken a little bit of time to get a firm grasp on what’s happening, but I think I’ve figured it out well enough to easily explain it.

If a Collection has notes that contain Timestamps and Classes, then Notenik will produce duplicate or inaccurate Timestamps, depending on a note’s Class and/or the method that the note is produced by. I’ve made multiple test collection to try and pin down exactly what’s happening, but this bug appears to depend on whether the Note was made via the New Note command or New Note w/ Options and the Class of the note itself.

It looks like Notenik sort of “groups” notes across a set of duplicate Timestamps. At most, I’ve gotten three individual Timestamps with which duplicates will be made from. How a note is “grouped” depends on how it was made.

For example, the first Timestamp in a Collection, 20230429214739 will be given to all Notes with a default Class and all notes (irrespective of their Class) made with the New Note command (or Command-N). The second Timestamp, 20230429214800 will be given to all notes with the Class quotation that are made via the New Note w/ Options command (or Command-Option-N). A third Timestamp, 20230429214817 can be given to all notes with the Class summary that are made via New Note w/ Options.

I haven’t tested this bug out with more than three classes, but I imagine that a fourth note would receive a fourth Timestamp if it was made with the New Note w/ Options command.

The times provided in these Timestamps will also have inaccurate values in minutes and seconds (I understand that Timestamps are generated in GMT+0 and the hours are consistent with that).

Here is a sample collection (5.8 KB): I hope that it sort of captures what I’m trying to describe.

If I you feel like I haven’t been clear with certain parts of my description of this bug, please let me know. It’s a strange one. Thank you, Herb!

In regard to Timestamps generation:
I’m also observing that Notenik is generating some Timestamps that are incompatible with the 24–hour time format, e.g. 20230430240859. The 24th hour should be denoted with 00 instead of a literal 24.

Thanks for the bug reports! Looking into them now.

You are correct, in that Notenik is reporting hours in the 1 - 24 range, rather than the 0 - 23 range, when generating timestamp values.

Here is the relevant spec for the date and time formatting codes: unicode spec for date format patterns.

Notenik is currently using the following string: yyyyMMddkkmmss. It is the kk part that is causing the behavior in question. You’re suggesting I should instead use the HH code.

I think you’re correct in that the 0 - 23 range is more common. What’s more (and probably more important) is that use of the 1 - 24 range would cause a time of 12:30 am to come after a time of 12:30 pm!

I’ll make the change you suggest.

Thanks again!

1 Like

Interesting. I do love a nice visit to a technical standard. Thank you, Herb and I’m glad that I can help.

Great detective work! I think I’ve found and fixed the timestamp problem. Will post a beta soon so you can (hopefully) verify.

1 Like

Great news! I look forward to checking it out, thanks.

See the latest beta. I think this should fix the problem you found.