SV: Rumours

As far as I remember the problem with 7.3.3 is not with the storing of dates but that a problem will arise with exports in the year 2000. I believe there is a workaround, but it's still not year 2000 compiant.

Ronny Ivarsen
ivarsen_at_online.no

Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> skrev i meldingsnyheter:930863308.4309.3.nnrp-07.9e984b29_at_news.demon.co.uk...
>
> The question of how Oracle stores the date
> is not relevant. The point is: which database
> versions are deemed to be year 2000 compliant
> for support purposes, and the message delivered
> to the Unix SIG of the UKOUG by the official
> Oracle rep a short time ago was that for many
> platforms 7.3.4 is it.
>
> Naturally this caused a significant amount of
> grief since many of the attendees had completed
> their Year 2000 testing based on the statement
> made about a year ago that support purposes 7.3.3
> was the target version.
>
>
> --
>
> Jonathan Lewis (Chairman UKOUG Unix SIG)
> Yet another Oracle-related web site: www.jlcomp.demon.co.uk
>
>
> Pete Sharman wrote in message <377BC7A2.185EC088_at_us.oracle.com>...
> >OK, let's travel the road again. Seems I've been down this road a dozen
> times
> >now.
> >
> >Due to the way Oracle stores dates, the RDBMS in any release of version
8,
> 7, and
> >probably back to the year dot has not had an issue with Y2K, unless there
> has been
> >a bug. The century is always stored.
> >
> >How your ***application*** deals with displaying it is another issue.
> >
>
>
>
>
>
Received on Thu Jul 01 1999 - 17:43:20 CDT