> One could imagine having a more complicated structure that could cope with > the inherent ambiguity in future times. I can't say "schedule an event > exactly 1 year from now" for example without it. I need additional metadata > around to know if I want it to happen at the same time of day on the same > date or if I want it to happen after than many seconds have elapsed. You > can't convert a putative UTC time to TAI time until you are within 6 months > of that time (the current announcement schedule) because if you try to > compute that time too far in the future, it will change. ...
Could that be solved with 2 functions in the API, one for N seconds from now, and a second for at some future date/time specified in Y/M/D/H/M/S format rather than something like a time_t? -- These are my opinions. I hate spam. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
