[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is TS 5 next generation or not?



PureBytes Links

Trading Reference Links

> > BTW, what I don't understand is is TS 5.0 is a fantastic new re-write using
> >  true 32-bit code, why has the y2k bug been designed into it?  If it's going
> >  to be re-written, re-write it without the bug!
> 
> It is not a bug.  It is simply the way all software reads dates.   They are
> wise to do it the way they are.   Most unwise when making major changes to do
> more than one thing at a time.  Better to do all the changes for TS5.0 and
> then go back and make all the changes for the Y2K fix.  Other wise when
> problems occur its a lot harder to find the cause.

My point was if it is a redesign, designing in non-y2k compliance requires
a development effort as does designing in y2k compliance.  I design x86
microprocessors and as we go from generation to generation, we absolutely do
not design a machine that was compatible with the last generation then go
back and change the parts that need to be part of the next generation.  That
appraoch seem ludicrous unless we are not designing a true next generation
machine and are using the same design base.

I do not know Omega's reasons.  I presume they have them.  However, in
absence of an explanation from them, I am confused.  IS TS5.0 a next generation
product or not.  If it is, why is it not designed from the begining to be a
next generation product.

If TS5.0 is next generation and it has non-y2k compliance designed into it from
the begining, it is a bug.  Furthermore, development effort will be spent to
design in and test this non-y2k compliance bug.

I am stupified if this is the case.  I guarantee, I will not buy anything from
Omaga nor upgrade my TS with anything that is non-y2k compliant.  I am stunned
that TS5.0 ever had (or has) a plan to go out initially without y2k compliance.

The only conclusion I can draw is that TS5.0 is not a true next generation
ground up design.  It is built from a TS4 base that is 16-bit and also non-y2k
compliant.  Maybe I'm wrong but its the only explanation I know of that makes
sense.

For cyring out loud, designing a new piece of software that handles 4 digit
years instead of 2 is trivial.  It takes no more effort to do one over the
other.  Unless of course you are using old code!  Then it no longer qualifies
as a ground up design for the next generation.

Chris Norrie