Please describe the problem.
File modification metadata is stored separately as year, month and day according to the annex.genmetadata docs. This makes reading and writing it unnecessarily complicated. Also, every field has its own modification timestamp and two out of the three become meaningless once you change one. (Does the modification time field even need its own modification time field?)
It would be easier to work with if it was represented as a UTC unix timestamp or ISO 8601 string or something similar, ideally something date(1) and/or touch(1) (GNU and BSD) will understand natively. Also, you could fit more precision in there for little cost.
What steps will reproduce the problem?
git annex metadata <any file with modification metadata>
What version of git-annex are you using? On what operating system?
git annex 6.20180227, various Linuxes.
The year, month and day fields are used when creating views that sort files by modification date, eg.
git annex view year=* month=* day=*. This cannot be done using timestamps. I agree that an additional timestamp field is a good idea, so I modified the pre-commit-annex hook by addingat the end of the process function.
One use case for the separate fields is
git-annex view, where they allow creating view branches with yyyy/mm/ subdirectories or artist/yyyy/ or whatever kind of thing the user wants.Part of the original metadata design, which never got implemented, was to allow pure functions on metadata, that added to the set of available metadata. So a unix timestamp could be what's stored in metadata, and then the individual fields (and more fields that are currently omitted to avoid bloat) derived from it.
I'd be happy to see that part of the metadata design actually happen. There are some potential problems with it that need to be thought about, such as:
git annex metadatato change or delete such a derived metadata field?(BTW, the timestamps on metadata fields come for "free" in that the underlying metadata storage log necessarily contains timestamps of when each part of the metadata was changed.)
If pure functions were part of the design anyway, why not avoid adding derived fields and introduce functions like
year()etc instead? The semantics would be obvious (you don't assign to a function call) and existing workflows involving the year field would keep working.As for editing the timestamp in general, I'll post an answer to https://git-annex.branchable.com/bugs/proposal_for_timestamp_semantics/ later that should address this.