Maxim: Thank for the clear explanation. My little problem seems to require a super steam hammer. Your insights are most helpful.
Alan On Fri, Dec 11, 2020, 07:46 Maxim Nikulin <maniku...@gmail.com> wrote: > 2020-12-11 Alan E. Davis wrote: > > > > I had hoped that subtracting 10 hours from 06:44 UTC would get me at > > least -04:44. > > I am in doubts how to present negative time correctly. Having in mind > wall clocks with hands, your expectation has some sense. > > I think, the source of confusion is that you are trying to use > facilities intended for TimeInterval + TimeInterval arithmetic, where > TimeInterval denotes a type. Actually you need to compute Time + > TimeInterval. Sorry, I am unaware if Emacs provides proper functions. > > There are a lot of subtle issues with time-related operations, but most > of DST complications pointed out by Tim could be handled with IANA > (Olson) DB for time zones, on Linux it is almost always installed as > tzdata package and is getting regular updates. It is rather precise and > contains history of DST and other transitions. If people complains on > incorrect results, usually they have wrong timezone set on their computers. > > For astronomy the best representation should be timestamp (seconds since > epoch) converted to local date time when necessary. Unsure concerning > leap seconds. > > Human-related future events mostly should be stored as date + local time > + label of administrative region that allows to get time zone ID (namely > ID, not offset from UTC). Time offset could be changed after event has > been planned, time zone could be split into several ones with distinct > offsets. > > - LocalTime + TimeInterval operation could give incorrect result unless > LocalTime is augmented with date and TimeZone, the latter is the history > of transitions. > - TimeZone (e.g. Europe/Berlin) as full transition history is not the > same as TimeOffset at particular moment (+0100). > > Carefully choose storage format: > - just Date e.g. for date of birth (adding time or time zone could > distort results), > - Date + LocalTime + Place for planned events > - Timestamp for most events in past. Use it for future if local time is > irrelevant, astronomical events is an example. > > Conversion to local time could evolve due to administrative decisions. > > Examples when Olson DB is not enough and additional negotiations or > justifications are necessary: > > - (March, 31) - (1 month) > - Conversion from Date + LocalTime to Timestamp around time transition > when non-existing or ambiguous local time is possible. > > >
