"RokuMarkn" wrote:
I don't really view calculations in GMT as a subset of the general problem.
Well ... it is an it isn't.
🙂 "Having your inputs already in GMT" is the subset I was referring to -- those cases when you don't have to convert your inputs from local time to GMT in the first place. But see below for other ways in which this might be considered a subset.
"RokuMarkn" wrote:
IMHO the right way to handle date/time is to do all calculations in epoch-based GMT times, and only use the broken-down form (day,month,year,etc) for display.
That is an excellent first approximation of correctness, especially if nasty bits like leap seconds, range limitations, etc. can be safely ignored (which is really the vast majority of the time, no pun intended). You can get a little better for some use cases by using TAI instead, but most people these days expect GMT calculation for non-scientific needs, so it's a good default. Once you get into scientfic uses, all bets are off, and there are time bases galore for special purposes.
"RokuMarkn" wrote:
Time zones and DST take part in the conversion of an internal epoch date to a displayable form but they don't affect any date calculations, such as the duration between two dates or the date X days before/after a given date, which can be done easily using epoch based dates.
That is indeed a common choice of interpretation that doesn't
always DWIM unfortunately. For a simple example of why this is not
necessarily correct, try this: "What is the duration in hours between noon January 1, 2010 and noon July 1, 2010?" Is the person asking for actual hours they lived in the six months between those two dates in their local timezone? Or are they looking for the answer in the 'floating' timezone, the abstract zone in which no DST occurs and the conversion to GMT is undefined, but for which a day always equals 24 hours? Would they be surprised if the answer was exactly divisible by 24, or if it wasn't?
Sure, if you're doing only date math (with "day" as the smallest unit), that issue doesn't occur. But then there is no defined conversion to epoch seconds (regardless of timezone). To make sure you only deal with round days and avoid rounding errors, you might convert to a timezone with no leap seconds. But since most system libraries do things in GMT, you'd have to do your own correction anyway, so you might as well do the math in RD (Rata Die) days and be done with it.
(Please excuse the pedantry, BTW. Unfortunately "time" (like "character set") is such a slippery concept that it is unreasonable to expect anyone to simultaneously understand it completely and actually get useful work done. For the rest of us, it's probably most important to simply know that the rules of thumb are only that, and don't
always apply. I know that I was in for a serious mental shock when I first began to study this stuff. "There is unexpected depth in
all fields of endeavor.")
