Max Nikulin <maniku...@gmail.com> writes: > On 22/01/2023 14:48, Tim Cross wrote: >> Timestamp for a log >> record I would probably want <YYYY-MM-DD HH:MM Z> or one of the >> variants because the most common way I use those types of timestamp is >> in diagnosing problems and comparing revords from various locations >> where I don't care about the local time where the record was generated, >> but with when it occurred in relation to other log recores. > > I agree that it is more convenient to have uniform offset in such case, > especially in the > case of multiple files having their specific timezone. During trips I do not > expect so > much changes of timezone to make comparison of timestamps significantly > harder. > >> I would argue that all depends on how you use the information. My org >> files are consumed by me (reading) and by scripts, elisp and other >> programs. > > For scripts given offset should not be an issue at all. And it is up to you > if you prefer > to have UTC instead of local time offset in you files. > >> My preference is for a timestamp syntax which lets the user select the >> format they want and not attempt to restrict it more than that. > > I do not mind to provide a user option for preferred storage format used for > clock entries > and similar stuff. > >> Provided >> you can specify timestamp with and without TZ information and you >> support full and abbreviated time zone names as well as UTC, I don't >> think it mattters - let the user choose what suits them best. > > Concerning time zone abbreviations, I would discourage them as much as > possible for > storage format. They may be added to overlay though. Perhaps US residents > would be unhappy > by such decision, but there are enough examples of the same abbreviation for > completely > unrelated locations. Abbreviation may be useful in addition to timezone ID to > disambiguate > local time close to a backward time jump. > > Tim, in your last messages I do not see statements causing my objections any > more. It > seems we came to agreement: flexible enough storage format and configurable > display format > for overlays. Have I forgot anything?
No, I think you have covered everything. I think most of your remaining concerns can be adequately covered via some updated documentation and with some luck, people will add some use case workflows to worg showing how using different storage formats and display overlays can address various scenarios.
