RISC OS4 - Millennium Compliance
Kade Hansson
>
> RISCOS Ltd Millennium compliance statement
> ------------------------------------------
>
[snip]
> In order to comply with this, the following calls have changed slightly
> in their operation:
>
> OS_Word 14,1
>
> This call returns the current time as a set of BCD values. You should
> treat the year in the following manner :
>
> if year < 66 then
> fullyear = 2000 + year
> else
> fullyear = 1900 + year
This will only work until 2065. If a full year value is required,
shouldn't the call's return values be used in conjunction with the CMOS
RAM century value to calculate the full year?
Of course, I agree that if you want to obtain a full year value, OS_Word
14,1 is not the right call to be using. But you guys did bring it up...
:-)
Archer
End.
Reuben Thomas
>This will only work until 2065. If a full year value is required,
>shouldn't the call's return values be used in conjunction with the CMOS
>RAM century value to calculate the full year?
I think that by 2065 OS_Word will be safely obsolete and removed, and I'd be
moderately surprised if RISC OS were still around.
OTOH, a somewhat hacked version of RISC OS 4 will probably be running the
entire 'net (good Lord! only someone over the age of 80 would be pompous
enough *still* to put the apostrophe in "'net"; that's like writing "'phone"
for "telephone" 100 years ago!).
--
http://sc3d.org/rrt/ | certain, a. insufficiently analysed
Matthias Seifert
> On Wed, 21 Jul 1999 01:21:18 GMT, Kade Hansson
> <kad...@postoffice.utas.edu.au> wrote:
> >This will only work until 2065. If a full year value is required,
> >shouldn't the call's return values be used in conjunction with the CMOS
> >RAM century value to calculate the full year?
> I think that by 2065 OS_Word will be safely obsolete and removed, and
> I'd be moderately surprised if RISC OS were still around.
Erm, that kind of logic _is_ the reason for the Y2K problem... :-(
--
_ _ | Acorn Risc PC, StrongARM @ 287 MHz
| | | _, _|__|_ |) ' _, , | 256+2 Mbyte RAM, >40 Gbyte HD
| | | / | | | |/\ | / | / \ | ------------------------------------
| | |_/\/|_/|_/|_/| |/|/\/|_/ \/ | http://www.deutschlandwetter.de
Reuben Thomas
>Reuben Thomas <r...@persephone.joh.cam.ac.uk> wrote:
>> I think that by 2065 OS_Word will be safely obsolete and removed, and
>> I'd be moderately surprised if RISC OS were still around.
>
>
>Erm, that kind of logic _is_ the reason for the Y2K problem... :-(
True, but take it in context. First, a different time-span (about 60 years
to 2065, whereas non-Y2K-compliant systems tend to be less than 30 years
old). Secondly, RISC OS has been used mostly in systems with quick turnover
(workstations, embedded devices), not the long-lasting mainframe systems
which cause most of the Y2K problems. (The point is not that the hardware
has a quick turnover, but that the OS does; this is partly due to hardware).
However, my second paragraph, which you deleted, made exactly the point you
make above.
Justin Fletcher
Kade Hansson <kad...@postoffice.utas.edu.au> wrote:
> Gareth J Dykes wrote:
> >
> > RISCOS Ltd Millennium compliance statement
> > ------------------------------------------
> >
> [snip]
> > In order to comply with this, the following calls have changed slightly
> > in their operation:
> >
> > OS_Word 14,1
> >
> > This call returns the current time as a set of BCD values. You should
> > treat the year in the following manner :
> >
> > if year < 66 then
> > fullyear = 2000 + year
> > else
> > fullyear = 1900 + year
>
> This will only work until 2065. If a full year value is required,
> shouldn't the call's return values be used in conjunction with the CMOS
> RAM century value to calculate the full year?
No, you should bloody well do it properly! I'm just confirming that the
operation of the call is defined and that is the way that OS_Word 14,1 works.
You don't use it if you want your programs to work after that.
> Of course, I agree that if you want to obtain a full year value, OS_Word
> 14,1 is not the right call to be using. But you guys did bring it up...
> :-)
It completes the statement of millenium compliance. That's all...
--
Justin Fletcher, Software Engineer, RISCOS Ltd
[ Opinions expressed are not necessarily those of my employer ]
Charlie Baylis
Kade Hansson <kad...@postoffice.utas.edu.au> wrote:
[snip code]
> This will only work until 2065. If a full year value is required,
> shouldn't the call's return values be used in conjunction with the CMOS
> RAM century value to calculate the full year?
That still breaks code which refers to old dates.
> Of course, I agree that if you want to obtain a full year value, OS_Word
> 14,1 is not the right call to be using. But you guys did bring it up...
> :-)
AIUI the government has defined this behaviour to be acceptable, and any
other behaviour to be unacceptable. I imagine that this announcement was
simply to conform to that.
Of course, in reality it's completely irrelevant, because this call is not
used in new software so there's nothing to take advantage of it's "millenium
compliancy", and old software breaks anyway.
Has anybody actually found a RISC OS program which uses OS_Word 14,1?
Charlie
--
New RISC OS mp3 player: http://www.fish.zetnet.co.uk/
Chesney
Matthias Seifert <M.Se...@t-online.de> wrote:
> Reuben Thomas <r...@persephone.joh.cam.ac.uk> wrote:
> > On Wed, 21 Jul 1999 01:21:18 GMT, Kade Hansson
> > <kad...@postoffice.utas.edu.au> wrote:
> > >This will only work until 2065. If a full year value is required,
> > >shouldn't the call's return values be used in conjunction with the CMOS
> > >RAM century value to calculate the full year?
> > I think that by 2065 OS_Word will be safely obsolete and removed, and
> > I'd be moderately surprised if RISC OS were still around.
> Erm, that kind of logic _is_ the reason for the Y2K problem... :-(
In general, yes, but in this case, no. OS_Word 14, 1 has been depreciated
for some time now, and the PRM already states that it should not be used and
is only included for backwards compatibility. The call is not generally used.
I assume that the only reason anything at all has been done is to allow 100%
Y2K compliance to be claimed, it is not as though it will have any practical
consequences.
--
Chesney
If you keep your mind sufficiently open, people will throw a lot of rubbish
into it. - William A. Orton
Gareth McCaughan
> OTOH, a somewhat hacked version of RISC OS 4 will probably be running the
> entire 'net (good Lord! only someone over the age of 80 would be pompous
> enough *still* to put the apostrophe in "'net"; that's like writing "'phone"
> for "telephone" 100 years ago!).
Eek. I write "'phone" and "'net". The former more often than the latter.
--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction
Matthias Seifert
> In message <49250ac94...@t-online.de>
> Matthias Seifert <M.Se...@t-online.de> wrote:
> > Reuben Thomas <r...@persephone.joh.cam.ac.uk> wrote:
> > > On Wed, 21 Jul 1999 01:21:18 GMT, Kade Hansson
> > > <kad...@postoffice.utas.edu.au> wrote:
> > > >This will only work until 2065. If a full year value is required,
> > > >shouldn't the call's return values be used in conjunction with the
> > > >CMOS RAM century value to calculate the full year?
> > > I think that by 2065 OS_Word will be safely obsolete and removed, and
> > > I'd be moderately surprised if RISC OS were still around.
> > Erm, that kind of logic _is_ the reason for the Y2K problem... :-(
> In general, yes, but in this case, no.
[...]
Well, I was not (really) refering to this particular case, but to the
argument that 'surely noone will use this until then'...
Geoff Crossland
r...@persephone.joh.cam.ac.uk (Reuben Thomas) wrote:
> I think that by 2065 OS_Word will be safely obsolete and removed, and I'd be
> moderately surprised if RISC OS were still around.
>
> OTOH, a somewhat hacked version of RISC OS 4 will probably be running the
> entire 'net (good Lord! only someone over the age of 80 would be pompous
> enough *still* to put the apostrophe in "'net"; that's like writing "'phone"
> for "telephone" 100 years ago!).
Well, I don't even plan to live that long and I
still make sure punctuation is correct on words such
as 'phone, 'flu' and Plug'n'Pray. Odd that Microsoft
didn't get it right with 95 (I'm refering to the
name, here).
Alas, in these days of popularist culture, being
right doesn't seem to count for much. Damn all these
humans...
--
Geoff Crossland
gcrossland @ eccentricity . freeserve . co . uk
iain truskett - koschei
<URL:mailto:cb-...@fish.zetnet.co.uk> wrote:
> In article <3795203D...@postoffice.utas.edu.au>,
> Kade Hansson <kad...@postoffice.utas.edu.au> wrote:
> Has anybody actually found a RISC OS program which uses OS_Word 14,1?
!BootBoard - uses OS_Word 14,1 to look up the month number (discards
the year number). There's a newer version around which doesn't use
OS_Word 14,1 though (why? I'm running Justin's module which makes any
all to OS_Word 14,1 return an error).
cheers,
--
iain. <http://eh.org/~koschei/>
Famous last RPG words, number 900 -
"That's right, I'm going to polymorph into a pergrine falcon and
attempt to land on the back of one of the 12 griffons flying above us."
Ant Support (Paul)
<URL:mailto:kos...@eh.org> wrote:
> !BootBoard - uses OS_Word 14,1 to look up the month number (discards the
> year number). There's a newer version around which doesn't use OS_Word 14,1
> though (why? I'm running Justin's module which makes any all to OS_Word
> 14,1 return an error).
Indeed. I can't see a problem if you're not using the year byte anyway. I use
it occasionally to find the day number of the month.
--
Paul Vigay
_ _________________________________
/_| _ _. _ /| /_ _/_ /' ANT Technical Support
/ || (_|(_)/ |/(/_/_ / mailto:ant.s...@argonet.co.uk
________ (_) ___________./ http://www.argonet.co.uk/ant/
Ant Support (Paul)
<URL:mailto:cb-...@fish.zetnet.co.uk> wrote:
> Has anybody actually found a RISC OS program which uses OS_Word 14,1?
I use it occasionally, but not for reading the year!
Chris Evans
<URL:mailto:no....@heyrick.co.uk> wrote:
> In article <3795203D...@postoffice.utas.edu.au>, Kade Hansson
> <kad...@postoffice.utas.edu.au> wrote:
>
>
>
> For example, year 207 would by 2107.
Yes but how do you know the user is not a historian or geologist and does
mean 207AD?
Chris Evans
--
CJE Micro's / NCS 'Acorn Centre of Technology'
Telephone: (01903) 523222 Fax: (01903) 523679
ch...@cje.co.uk http://www.cje.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN.
Liam Gretton
<URL:mailto:kos...@eh.org> wrote:
> (why? I'm running Justin's module which makes any all to OS_Word 14,1
> return an error).
Where did you get this from? It's not on Justin's website AFAICT.
--
Liam Gretton l...@star.le.ac.uk
Space Research Centre, http://www.src.le.ac.uk/
Physics and Astronomy Dept, phone +44 (0) 116 223 1039
Leicester University, fax +44 (0) 116 252 2464
Leicester LE1 7RH, UK http://xmm4.xra.le.ac.uk/
Matthias Seifert
> In article <3795203D...@postoffice.utas.edu.au>, Kade Hansson
> <kad...@postoffice.utas.edu.au> wrote:
> > This will only work until 2065.
> Can't you return 0 to xxx, and add 1900 to it?
> For example, year 207 would by 2107.
Erm, the values are BCD (binary coded decimal) and thus can only hold 0 to
99 in a byte...
Justin Fletcher
Liam Gretton <l...@star.le.ac.uk> wrote:
> In article <ant2202240b0Jgv#@150.203.115.93>, iain truskett - koschei
> <URL:mailto:kos...@eh.org> wrote:
> > (why? I'm running Justin's module which makes any all to OS_Word 14,1
> > return an error).
>
> Where did you get this from? It's not on Justin's website AFAICT.
It was something I passed around for people to test their softwares
compatibility long ago... At some point I might release it but... it's
/really/ not worth it!
Rik Griffin
Gareth McCaughan <Gareth.M...@pobox.com> wrote:
>Reuben Thomas wrote:
>
>> OTOH, a somewhat hacked version of RISC OS 4 will probably be running the
>> entire 'net (good Lord! only someone over the age of 80 would be pompous
>> enough *still* to put the apostrophe in "'net"; that's like writing "'phone"
>> for "telephone" 100 years ago!).
>
>Eek. I write "'phone" and "'net". The former more often than the latter.
Some people even write "CJE Micro's" ... ;-)
Oh no, what have I started now ?
--
"This moment hangs, like your ragged hair."
Celebrate - Fields of the Nephilim
Jonathan Graham Harston
> Gareth J Dykes wrote:
> > RISCOS Ltd Millennium compliance statement
> > ------------------------------------------
> [snip]
> > In order to comply with this, the following calls have changed slightly
> > in their operation:
> > OS_Word 14,1
> > This call returns the current time as a set of BCD values. You
should
> > treat the year in the following manner :
> > if year < 66 then
> > fullyear = 2000 + year
> > else
> > fullyear = 1900 + year
> shouldn't the call's return values be used in conjunction with the CMOS
> RAM century value to calculate the full year?
> 14,1 is not the right call to be using. But you guys did bring it up...
> :-)
the call should be used".
Osword14 has never been guaranteed to correctly return the year, most
explicitly because Osword14,1 only returns a two-digit year, so programs
have always needed to process the returned data before using it.
Some systems don't provide Osword14, so the returned data has to be
checked to see if there was returned data.
Some systems provide Osword14, but don't have a RTC, and return a default
string, which have to be checked for.
Some systems fetch the time&date from a server, but mess up, mixing the
year and date data, so these have to be checked for. (Some systems
thought that 1997 was 1981.)
As NetFS dates represent the year as a 7-bit offset from 1981, that has
always been the recommended pivot point, so code would do something like:
if year<81 then fullyear=2000+year else year=1900+year
When manipulating the date as a string, it is easier to use 1980 as the
pivot point with almost the same result, as it involves checking a single
character, so making code do something like:
if year[2]<'8' then year[0..1]="20" else year[0..1]="19"
So, IF using Osword14 to find the date
THEN process the result before using it
The following is the function I use when I need to compatibly use Osword
14 to read the time&date as a string:
DIM ctrl% 30
DEFFNtime:LOCALX%,Y%,A%:X%=ctrl%
Y%=X%DIV256:?X%=0:A%=14:CALL&FFF1:IF?X%=0:=""
X%?25=13:X%?15=13:A%=VALMID$($X%,5,2)DIV32
$(X%+11)=STR$(VAL$(X%+11)+16*A%-100*(VAL$(X%+11)<1981))
IFA%:X%?6=13:$(X%+4)=RIGHT$("0"+STR$(VAL$(X%+4)-32),2):X%?6=32
X%?15=46:=$X%
This reads the RTC regardless of what machine it is running on, and will
correct for years after 1996 and 1999, or return a null string if no time
is available. The 'Acorn Era' is defined as starting in 1981, so the
century range is 1981-2080.
See also:
http://www.libdems.force9.co.uk/usr/jgh/docs/ManPages/O/2OsWord14
http://www.libdems.force9.co.uk/usr/jgh/docs/ManPages/T/3Time
--
J.G.Harston (JGH BBC PD Library) 70 Camm Street, Walkley, SHEFFIELD S6 3TR
j...@arcade.demon.co.uk - Running on BBCs & Masters with SJ MDFS FileServer
Z80+6502/CoPro+Tubes/Econet+SJ -- http://www.libdems.force9.co.uk/usr/jgh/
Richard Walker
Charlie Baylis <cb-...@fish.zetnet.co.uk> wrote:
Ah, ha! Just seen this!
> Has anybody actually found a RISC OS program which uses OS_Word 14,1?
Yes. Termite's web browser. It uses it to stick the date/time in email
messages (from mailto: URLs) which are generated by it's built-in mailer
(anyone want to fix the OLE code?). Interestingly, it uses a similar
bodge to get around the date issue until about 2069...
Ta da! :-)
--
Richard.
"And he never shows his feelings, But the fool on the hill."