13 Jul
2012
13 Jul
'12
6:38 p.m.
On 2012-07-13 19:00, "Jerome H. Fine" <jhfinedp3k at compsys.to> wrote:
Johnny Billquist wrote:
Sorry, but I fail to see the point. The internal representation of a
date will almost by necessity be different between different OSes and
hardware. Having a bunch of 16 bit values represent a date on a PDP-8
would be incredibly stupid and difficult, not to mention that OS/8 have
no concept of time to more detail than a day. And even that needs to be
updated manually every day.
So, ignoring the internal format, which can't really be portable anyway,
you then get to representation. There will always be dates that cannot
be represented in whatever format you choose. So what is the point of
bringing up that argument? It is nice if the dates that you might
reasonably expect to be processes be possible to express on the system.
As for communicating with other systems, in the communication I would
suspect/expect that you use an intermediate format (a nice text string
for example) that both agree on. And then you can convert from the
internal format to and from this intermediate format, as long as the
date is within a range expressable on that system.
When you go outside the date range for the system, you can either try to
do something reasonable, or give an error. I think that is a choice that
is best left to the writers of the code to decide on a case by case basis.
By the way, Unix express time as a number of seconds since Jan 1, 1970,
00:00 UTC.
And time is horribly complex. You know that even if we keep it fairly
modern, different countries switched from Julian dates to Gregorian
dates at different times, the last being Russia, in the early 20th century.
If you really think that you can come up with a reasonable, portable
design, that is "universal", I think I know of a few organizations that
would like to hear from you.
Until then, I'm pretty much satisfied with things the way they already
are. Yes, OS/8 have been broken for 10 years now. But to fix it require
more than just changing the internal storage for the date.
RSX got fixed, and depending on which bits you look, it might stop
working right 2070(?), 2099, 2155 or 34667.
I don't know about RT-11, but I do know that RT-11 is totally separate
>[Snip]
>Ooo. So TECO-8 actually lie in their documentation... Even worse.
>A year in the range 1986-1994 would just have looked like 1970-1977.
>That's ugly of them.
What seems even more evident to me is that DEC took
(as most other companies did as well) the attitude that
even the internal representation of date and time was
not important enough to allow the same information to
be exchanged between operating systems on a consistent
basis. from RSX, and any problems are not shared, but unique.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol