On Friday, 04/08/2016 at 04:08 GMT, Paul Gilmartin <[email protected]>
wrote:
> On 2016-04-08, at 09:29, Hobart Spitz wrote:
>
> > I think that if you clearly document the distinction, then I would
think
> > that different behaviors for +hh:mm versus hh:mm would make sense.
> >
> > An alternative/additional solution, possibly too much trouble, would
be to
> > add a timezone to the time specification: E.g. 10:30-EST, 18:15-CDT,
> > etc. Why too much trouble? No all countries change clocks on the
same day.
> >
> IANA TZDATA accounts for this. Necessarily, it's no lightweight;
> utterly unsuitable for a CP function.
Why unsuitable? A DIAGNOSE that feeds "compiled" IANA TZDATA to CP would
suffice. CP would then provide it other guests upon request and could
perform temporal math via a DIAGNOSE interface.
o tzdata_size = f0("SIZE")
o tzdata = f0("TZDATA")
o tod_t TOD1 = f1("January 1, 2016, 17:00:00.000 EST")
o tod_t TOD2 = f2(TOD1,+04:12:27.123)
o tod_t TOD3 = f2(TOD2, +1d) [+1d not +24h!]
o HMSm_t HHMMSSmmm = f3(TOD2, "EST")
o HMSm_t HHMMSSmmm = f3(TOD2, "-4")
It does mean that programmers need to be CLEAR in their intent. Come,
come! Did you mean 24 hours from now or one day? Speak up, man! Speak
up! But that only happens if the semantics of the timing APIs don't
artificially constrain the programmer to ask the wrong question, leading
to a wrong answer.
GIGO. And when manipulating Time, we should give it our A Game. Too many
movies have been (will be) written about those misguided individuals who
gave (will give) the Time Machine an imprecise target.
Alan Altmark
Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
[email protected]
IBM Endicott
