Timestamps are proving to be troublesome. Some background:

RETRO runs on a 32-bit VM; this provides direct addressing
and use of only signed 32-bit values. As such, a current Unix
timestamp fits. But this becomes a problem after 2038, when
the value will overflow the signed range, making the value
negative.

Some options:

- split a 64-bit value and return as two cells
- choose a new starting date for the timestamp
- return the number of seconds and a counter, resetting
  when the overflow occurs, and incrementing the counter
  each time this occurs.
- return two values: a starting year and the number of
  seconds since January 1 of that year
- don't worry about it - will RETRO12 still be in use in
  2038?

I personally use the timestamp functionality only for a
single application, a web request log, which is enabled
while doing debugging of the application. But I can see
cases where, especially for embedded tasks, this might
become a problem.

The first option would be pretty much future proof, but
has a big drawback: RETRO has no words for dealing with
values that take more than a single cell. I have no plans
to introduce double cell words to RETRO, so doing this
may not be particularly useful.

The second option just kicks the problem down the road.

The third would work, but is somewhat inelegant and
would have some drift (since the initial rollover occurs
in early 2039, after the reset, 0 isn't January 1, so
the meaning of the counter would be more difficult to
track over time)

The fourth would solve things and allow more control; I
could maintain the use of the Unix epoch until the
end of 2038, at which point I'd choose a new epoch and
restart the timestamps relative to that. For logs, I'd
just include both the starting year and the actual stamp,
then do any needed calculations based on those values.
This would lose compatibility with Unix timestamps after
2038 though.

The easiest option is to do nothing, but: I do have plans
for using RETRO on embedded systems for data collection;
having a timestamp would be useful here, though I don't
need it to be a Unix timestamp for this purpose.
		
There is a final option: switch to 64-bit cells. I've held
off doing this as I don't often need a bigger numeric range
than 32-bits provide and the 64-bit image wastes a lot of
memory on strings. But it would let modern Unix timestamps
continue to work for much longer than I need to worry about.