On 3/14/2016 8:02 PM, rbowman wrote:
On 03/14/2016 04:34 PM, Mark Lloyd wrote:

Also, I didn't expect to see many problems with Y2K, as with Y2.038K.

I did some patching in the months leading up to Y2K but there really wasn't
that much. I was on call New Year's Eve but it passed uneventfully. Luckily
someone other than myself will have to worry about Y2038.

I saw "19A0" in one case. Caught me completely off guard
("Where the hell did that 'A' come from??"). But, thinking
about it for a few microseconds and it was obvious...

I now keep dates as ascii strings. It's not that much more work.

The tougher problem (and it will NOT be solved, here! : )
is thinking about temporal "REFERENCES"!

E.g., if I have an appointment "in 35 minutes" and I *bind* that
to the current time (it is roughly 8:40P here), then that would
suggest the appointment is at 9:15P. Assume I also have something
scheduled for 10:00P.

Now, if I adjust my local clock to make "now" be 8:45P, how
does that affect these two events? Is my appointment still
35 minutes in the future? And, the 10:00 event 5 minutes sooner
than it would have been had I not updated my clock?

What if I then set my clock *back* 5 minutes? Has anything changed??

Silly example. But, think about things that are days or weeks
hence. How do you "store" those times? And, how does your choice
of storage technique (e.g., early or late binding) affect when
they ACTUALLY occur?

Do you store "relative times" using a relative notation? And,
store the reference from which they were originally specified?
Or, convert everything to absolute times?

Do you convert absolute times to relative times and store the
reference?

I.e., when a person says "I have an appointment in 35 minutes",
does that really mean they will wait for the minute hand to make
35 complete revolutions before the appointment begins? Or,
have they done some mental arithmetic and decided to express
the ABSOLUTE time of the appointment in relative terms (for
the benefit of whomever they are conversing with)?