From Newsgroup: comp.sys.apple2

<< Runing ProODS 8 (2.0.3) under KEGS-OSX on a PowerMac, I see that some files have a year of 103, while others display 03. The former show up in
the catalog as <NO DATE>. Is there a optimal way to deal with this? >>

No.
Old clock card system from the time when memory was expensive. Just the last two digits (03) are present for the computer to read, so unless the program you're running is set up for it, it will assume it's 1903.



--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Hi, y'all!

obsbedia2@aol.com (Obsbedia2) wrote in message news:<20030709060226.00112.00000037@mb-m03.aol.com>...

<< Runing ProODS 8 (2.0.3) under KEGS-OSX on a PowerMac, I see that some files have a year of 103, while others display 03. The former show up in
the catalog as <NO DATE>. Is there a optimal way to deal with this? >>

No.
Old clock card system from the time when memory was expensive. Just the last two digits (03) are present for the computer to read, so unless the program you're running is set up for it, it will assume it's 1903.

See ProDOS Technical Note number 28, written by Dave Lyons on
September 1990. It discusses the layout of the ProDOS date field.

The year field is a 7 bit field. So it can hold values from 0 to
127. The Technical Note says that values 100 to 127 are invalid. It
is my contention that they should be valid and should represent the
years 2000 to 2027.

ProDOS versions 2.0.x will ensure that the year field is in the
range 0 to 99 when reading the clock on a IIgs. Earlier versions do
not change the year field when reading the clock on a IIgs.

Willi
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

In article <3d7aa99a.0307090652.7cfbc835@posting.google.com>,
willi@wilserv.com (Willi Kusche) wrote:

Hi, y'all!

obsbedia2@aol.com (Obsbedia2) wrote in message news:<20030709060226.00112.00000037@mb-m03.aol.com>...

<< Runing ProODS 8 (2.0.3) under KEGS-OSX on a PowerMac, I see that some files have a year of 103, while others display 03. The former show up in the catalog as <NO DATE>. Is there a optimal way to deal with this? >>

No.
Old clock card system from the time when memory was expensive. Just the last
two digits (03) are present for the computer to read, so unless the program you're running is set up for it, it will assume it's 1903.

See ProDOS Technical Note number 28, written by Dave Lyons on
September 1990. It discusses the layout of the ProDOS date field.

The year field is a 7 bit field. So it can hold values from 0 to
127. The Technical Note says that values 100 to 127 are invalid. It
is my contention that they should be valid and should represent the
years 2000 to 2027.

ProDOS versions 2.0.x will ensure that the year field is in the
range 0 to 99 when reading the clock on a IIgs. Earlier versions do
not change the year field when reading the clock on a IIgs.

Willi

Thanks to everyone who responded. I think I was making a problem where
none existed! The bogus dates crept in under an older version of ProDOS,
and they've tagged along as I've moved from Apple II hardware to
emulation with disk images. I zapped 'em with Glen Bredon's BlockWarden program, more for aesthetics than because anything was broken:-)

BTW, I found a nice collection of Technical Notes at

http://web.pdx.edu/~heiss/technotes/tn.0.html#toc

John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

John B. Matthews <nospam@nospam.com> wrote in message news:nospam-9FFA34.04264909072003@clmboh1-nws3.columbus.rr.com...

Runing ProODS 8 (2.0.3) under KEGS-OSX on a PowerMac, I see that some
files have a year of 103, while others display 03. The former show up in
the catalog as <NO DATE>. Is there a optimal way to deal with this?

Sorry of this a FAQ.

Has the source code for ProDOS been posted anywhere? It would be
astoundingly easy to fix this problem if we had the source code.

- Mike


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Willi Kusche wrote:

Hi, y'all!

obsbedia2@aol.com (Obsbedia2) wrote in message >news:<20030709060226.00112.00000037@mb-m03.aol.com>...

<< Runing ProODS 8 (2.0.3) under KEGS-OSX on a PowerMac, I see that some >> files have a year of 103, while others display 03. The former show up in
the catalog as <NO DATE>. Is there a optimal way to deal with this? >>

No.
Old clock card system from the time when memory was expensive. Just the >last
two digits (03) are present for the computer to read, so unless the program >> you're running is set up for it, it will assume it's 1903.

See ProDOS Technical Note number 28, written by Dave Lyons on
September 1990. It discusses the layout of the ProDOS date field.

The year field is a 7 bit field. So it can hold values from 0 to
127. The Technical Note says that values 100 to 127 are invalid. It
is my contention that they should be valid and should represent the
years 2000 to 2027.

ProDOS versions 2.0.x will ensure that the year field is in the
range 0 to 99 when reading the clock on a IIgs. Earlier versions do
not change the year field when reading the clock on a IIgs.

In many ways, it would have simplified things if Apple had made
this choice, since relatively date-unaware programs would at
least sort years properly. ;-)

But Apple chose to go a different route, with year values from
40-99 meaning 1940-1999 and years from 00-39 meaning
2000-2039. Relatively little software actually implements
this fold point, but having the definition out there certainly
biases the argument!

Glen Bredon (ProSel) took the route you prefer, by issuing
a patched version of ProDOS (or just the clock driver?).

Bev Cadeaux (sp?) took the Apple-recommended route with
her updates to Appleworks and the ProSel utilities (though
the year sorting order was not addressed--only the correct
handling and preservation of dates beyond 1999).

If a spate of new software or updates arrive for the Apple II,
this issue will need to be resolved. Certainly, the "official"
opinion of Apple must weigh heavily in this resolution.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page: http://members.aol.com/MJMahon/
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Michael J. Mahon <mjmahon@aol.com> wrote in message news:20030710024051.00221.00000126@mb-m03.aol.com...

But Apple chose to go a different route, with year values from
40-99 meaning 1940-1999 and years from 00-39 meaning
2000-2039. Relatively little software actually implements
this fold point, but having the definition out there certainly
biases the argument!

...snip...

If a spate of new software or updates arrive for the Apple II,
this issue will need to be resolved. Certainly, the "official"
opinion of Apple must weigh heavily in this resolution.

Actually, I think we should come up with something better than either of
these approaches or we'll be having the same discussion in 36 years. ;-)

- Mike


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2



"Charlie" <charlied@NOSPAMbboard.com> wrote in message news:beo27004sj@enews1.newsguy.com...

"Bill Garber" <willy46pa@comcast.net> wrote in message news:K-qdnUTUh5DObZOiXTWJgQ@comcast.com...

"Charlie" <charlied@NOSPAMbboard.com> wrote in message news:bel7pd01nou@enews2.newsguy.com...

"Michael J. Mahon" <mjmahon@aol.com> wrote in message news:257d7207.0307101716.1ea07009@posting.google.com...

"Michael Pender" <mpender@hotmail.com> wrote in message

news:<x49Pa.71588$n%5.56799@nwrddc02.gnilink.net>...

Michael J. Mahon <mjmahon@aol.com> wrote in message news:20030710024051.00221.00000126@mb-m03.aol.com...

But Apple chose to go a different route, with year values from 40-99 meaning 1940-1999 and years from 00-39 meaning
2000-2039. Relatively little software actually implements
this fold point, but having the definition out there certainly biases the argument!

...snip...

I believe all the file creation and mod fields (date and time) take up

four

bytes which contain 5 unused bits (although they are in the field used

for

time). Using those 5 bits in conjunction with the 7 bits already

allocated

would have allowed 4096 years. Why this wasn't done originally is a

mystery to

me.

I would assume that it is because Apple didn't think anyone would still
be using/caring about the Apple II computers for this long. ;-)

I suppose you are right, Bill, At least about Apple the company but it is

hard

to understand why the people who actually did the programming would waste

five

bits on every file that was ever created in ProDOS while at the same time skimping on the number of bits used for the year field.

Charlie

Could be they wanted to remain compatible with existing software,
which is ludicrous if using the extra bits would improve on ability
to keep track of when files were written, but hey, what do we know,
right? ;-)

Bill @ GarberStreet Enterprises };-)
Web Site - http://garberstreet.netfirms.com
Email - willy46pa@comcast.net



---
This email ain't infected, dude!

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.495 / Virus Database: 294 - Release Date: 6/30/03


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2

Charlie wrote:

"Bill Garber" <willy46pa@comcast.net> wrote in message news:K-qdnUTUh5DObZOiXTWJgQ@comcast.com...

"Charlie" <charlied@NOSPAMbboard.com> wrote in message >>news:bel7pd01nou@enews2.newsguy.com...

"Michael J. Mahon" <mjmahon@aol.com> wrote in message >>>news:257d7207.0307101716.1ea07009@posting.google.com...

"Michael Pender" <mpender@hotmail.com> wrote in message

news:<x49Pa.71588$n%5.56799@nwrddc02.gnilink.net>...

Michael J. Mahon <mjmahon@aol.com> wrote in message >>>>>news:20030710024051.00221.00000126@mb-m03.aol.com...

But Apple chose to go a different route, with year values from >>>>>>40-99 meaning 1940-1999 and years from 00-39 meaning
2000-2039. Relatively little software actually implements
this fold point, but having the definition out there certainly >>>>>>biases the argument!

...snip...

I believe all the file creation and mod fields (date and time) take up

four

bytes which contain 5 unused bits (although they are in the field used for >>>time). Using those 5 bits in conjunction with the 7 bits already

allocated

would have allowed 4096 years. Why this wasn't done originally is a

mystery to

me.

I would assume that it is because Apple didn't think anyone would still
be using/caring about the Apple II computers for this long. ;-)

I suppose you are right, Bill, At least about Apple the company but it is hard
to understand why the people who actually did the programming would waste five
bits on every file that was ever created in ProDOS while at the same time skimping on the number of bits used for the year field.

Charlie

Actually the layout makes sense. I'll refer to the Beneath Apple ProDOS
as a reference.

Directory Headers:
$1C:Creation Date = YYYYYYYM MMMDDDDD
$1E:Creation Time = 000HHHHH 00MMMMMM

Try to manipulate the fields in 6502 and you'll see why. It's easier to
do this:
LDY #DATE
LDA (HDR),Y
AND #YEARMASK
LSR #YEARSHIFT
; A = year

than to manipulate a 32-bit word when extracting or setting date time.

Using a "window" format is used in a lot of places, MS Access and Oracle
to name a few.

Jim
--
Remove SPAM BAIT from address to reply

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


"jim symolon" <jsymolon01@SPAMattbiBAIT.com> wrote in message news:BEUPa.41713$OZ2.7395@rwcrnsc54...

Charlie wrote:

"Bill Garber" <willy46pa@comcast.net> wrote in message news:K-qdnUTUh5DObZOiXTWJgQ@comcast.com...

"Charlie" <charlied@NOSPAMbboard.com> wrote in message >>news:bel7pd01nou@enews2.newsguy.com...

"Michael J. Mahon" <mjmahon@aol.com> wrote in message >>>news:257d7207.0307101716.1ea07009@posting.google.com...

"Michael Pender" <mpender@hotmail.com> wrote in message

news:<x49Pa.71588$n%5.56799@nwrddc02.gnilink.net>...

Michael J. Mahon <mjmahon@aol.com> wrote in message >>>>>news:20030710024051.00221.00000126@mb-m03.aol.com...

But Apple chose to go a different route, with year values from >>>>>>40-99 meaning 1940-1999 and years from 00-39 meaning
2000-2039. Relatively little software actually implements
this fold point, but having the definition out there certainly >>>>>>biases the argument!

...snip...

I believe all the file creation and mod fields (date and time) take up

four

bytes which contain 5 unused bits (although they are in the field used for >>>time). Using those 5 bits in conjunction with the 7 bits already

allocated

would have allowed 4096 years. Why this wasn't done originally is a

mystery to

me.

I would assume that it is because Apple didn't think anyone would still >>be using/caring about the Apple II computers for this long. ;-)

I suppose you are right, Bill, At least about Apple the company but it is

hard

to understand why the people who actually did the programming would waste

five

bits on every file that was ever created in ProDOS while at the same time skimping on the number of bits used for the year field.

Charlie

Actually the layout makes sense. I'll refer to the Beneath Apple ProDOS
as a reference.

Directory Headers:
$1C:Creation Date = YYYYYYYM MMMDDDDD
$1E:Creation Time = 000HHHHH 00MMMMMM

Try to manipulate the fields in 6502 and you'll see why. It's easier to
do this:
LDY #DATE
LDA (HDR),Y
AND #YEARMASK
LSR #YEARSHIFT
; A = year

than to manipulate a 32-bit word when extracting or setting date time.

Using a "window" format is used in a lot of places, MS Access and Oracle
to name a few.

Yes, it is easier the way they did it, but when writing an disk operating system the need to make the programmer's job easier is, I believe, a little less important than having a system that works properly for all the rest of the people who use it. It probably would have taken the programmer an extra 10 or 15 minutes to write and yes it would have used a few more bytes of code but the end result would have been well worth it. At least in my opinion.

Charlie








--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.apple2


"Michael J. Mahon" <mjmahon@aol.com> wrote in message news:20030712212553.14728.00000298@mb-m07.aol.com...

Charlie wrote:

At the time that ProDOS was written most software on the Apple II ran under >DOS
3.3 which has no support for date and time stamping. It is possible that >programs that ran under other systems (Apple III SOS, CP/M, Pascal, etc.)

may

have had a similarly bit challenged date system (I don't know enough about >those systems to argue the point) but from what I've seen of Apple (the >company) over the years, compatibility isn't high on their list of >priorities.

Whatever the reasons for the original design choices (like trying to keep date and time as independent 16-bit fields) or the consequences for
post-1999 systems, the fact remains that this date format was made
an externally visible interface for ProDOS, and so cannot be changed
now without either: 1) changing all applications that use the date
structure (a very unappealing choice),

Agreed. Breaking existing programs is rarely a good idea. My reason for pointing out the unused bits was not to suggest that they now be used but only that when ProDOS was initially conceived there was room for more years.

or 2) adding a _new_ date
interface to ProDOS which preserves some kind (Apple's kind?)
of compatibility for unchanged applications and adds a new date
interface for applications which can be changed to take advantage
of it.

One way would be to just keep the _new_ dates in an indexed file. A program or a new (patched) version of ProDOS could look up the date in the file. If not found it would fall back on the old way.

Although the second alternative is appealing, it has the problem
that it is unlikely that many applications would actually exploit
it in the coming years.

True.

I'm also unsure of how much free space is available for ProDOS
changes these days...

This may be the show-stopper.

Charlie



--- Synchronet 3.18b-Win32 NewsLink 1.113