[NTLK] Date issues, who is responsible? Some background, and why the Newton died.

 L.W. Brown wrote:
>Come on - it was Sculley, not Jobs, who OK'ed too few digits to go
>beyond 2010;
In general, that is not how software development works. The CEO does not
dictate things as trivial as the number of digits used in a date. That
decision would fall to the development group who would weigh all of the
various conflicting requirements like integer size, when the epoch is, what
granularity you can get away with, can you get it all done by ship date, and
how much time do you have before you have to fix the problem?
Remember, UNIX originally used a 32 bit time stamp that incremented at 60hz.
This led to problems after 2.5 years. They redefined the tick rate to 1hz
which resulted in 130 years of range (+/- 68 years). They also redefined
their epoch. UNIX will blow up on January 19, 2038 unless the systems move
to64 bit time stamps.

The zune uses a 1 hz tick rate to increment the day and has an epoch of
January 1, 1980 and rolls over after 32767 days (but their code says that
themaximum year is the epoch + 100 which is around 36525 days, BUG!).

From where I sit, the Newton group had about 10 years to come up with a
workaround. Unfortunately they were scattered to the wind before it became
anissue.

The basic issue is that the time calculations that deal with time containing
seconds work with integers, and as of January 5th, 2010 the number of
secondsthat have gone by since January 1, 1993 is greater than an integer
canhandle.

The Newton uses two formats for dates, number of minutes since January 1,
1904 and the number of seconds since 1993. It appears that the problem lies
with the functions dealing with the date in seconds, the date functions that
deal with years, months, and days have plenty of space left. It looks like
the value is stored in a 29 bit value. All hell should break loose at second
2**29 which would be January 5, 2010 at 18:48:31.

The system routine TimeInSecondsToTime() returns an unexpected value. If you
give it the largest 29 bit value it gives a correct answer, but if you give
it a 30 bit number it screws up. But the routines that handle date
conversions handle the later dates. Try this sequence in the NTK debugger:

0x1fffffff

#7FFFFFFC 536870911
TimeInSecondsToTime(0x1fffffff)

#D4B4820 55759368
TimeInSecondsToTime(0x20000000)

#90703E0 37863672
datentime(TimeInSecondsToTime(0x1fffffff))

#C6330BD "1/5/10 18:48"
datentime(TimeInSecondsToTime(0x1fffffff)+1)

#C6333AD "1/5/10 18:49"
datentime(TimeInSecondsToTime(0x20000000))

#C633285 "12/28/75 5:12"
datentime(TimeInSecondsToTime(-0x20000000))

#C66F319 "12/28/75 5:12"

TimeToTimeInSeconds is likewise screwed:

timetotimeinseconds(55759368,31)

#7FFFFFFC 536870911
timetotimeinseconds(55759368,32)

#80000000 -536870912

If you try to set the time using SetTimeInSeconds with a large value, it
willblow up:

settimeinseconds(536870912)
// Error: -48622
// File: <Inspector>
// Line: 1
// Invalid decimal integer: "536870912"<information not available> (out of
range)

So, is it possible that the low level routines could be patched to handle
larger values? Take this statement from "The NewtonScript Programming
Language" P2-10 into consideration - "Integers range from 536870911 through
-536870912. When the limit is exceeded behavior is undefined." An integer in
NewtonScript is only a 29 bit value, not a 32. The extra 3 bits are used
internally. Perhaps if these routines were reimplemented in C? No, the
valuescould not be stored since they would be too big? Redefine the
incrementto something like 16 second chunks? That might work as long as
everybody calling the routines knows that the increment has changed.

As for why the Newton was killed off, the way that it was explained to me
(references lost), was that microsoft threatened to stop development of
Office for Mac. A meeting was called between Steve Jobs and Bill Gates. Bill
wanted to get rid of the competition to windows CE, Steve wanted Office for
Mac. An arrangement was made (probably involving assuring that nobody could
take over the Newton project, therefore getting the source code would be a
breach of contract).

Andrei

====================================================================
The NewtonTalk Mailing List - http://www.newtontalk.net/
The Official Newton FAQ - http://www.splorp.com/newton/faq/
The Newton Glossary - http://www.splorp.com/newton/glossary/
WikiWikiNewt - http://tools.unna.org/wikiwikinewt/
====================================================================
Received on Mon Jan 5 01:23:55 2009