=====
Technically, we’ll probably end up saving 2 dates for each log entry:
auto-assigned date when the user actually entered the data
user-supplied date (if they edited it)
We’ll always display the user-supplied date (if it exists), but data-exports will include both dates. In general that just seems like a safer design, but it might also be useful in the future for audits… by the health inspectors, or by warranty departments. I suspect that many people will value this immutability in the long-term, but it’s just a guess for now.
@gazzini I think it’s a great idea for users to be able to input a manually date. This allows people to go back and log older entries with the correct date and time, also useful when multiple days of entries need to be logged. Great idea!
That sounds great. The audit feature as unchangeable is great. If there is an audit and the date discrepancy is questioned, the user will have to come up with a viable explanation… I would recommend at minimum keeping a paper log book that can be referenced as a backup.
Thanks @katiehorbal for the design here – we’re going with this for V1. Pressing the date will bring up a system-standard datetime selector (on iOS, that’s the flat-rolodex-scrolly thing).