🚀 go-pugleaf

The first question would be, why would you use a variant to store a date?  The
overhead cost of variants is astronomical.  Use a double and solve two (2)
problems.  Your date situation and the overhead hammering your causing using a
variant.

BTW, MS says that VB (no matter what version) uses Y2K compatible date
routines.

Gordon

In article <01bfa79b$a1ea0060$03ef98c3@novix>,
  "Tim Foster" <TimF@Romtec.co.uk> wrote:
>
> Can anyone help provide information on what the status of Year 2000
> compliance is concerning VB3 and VB4 16-bit apps (using Access 2
> databases).
>
> After some testing in a VB4 16-bit application, I'm fairly positive there
> is a problem reading dates into Variants (VB seems to be trimming the dates
> to Short Format), and so when the Year 2000 rollover occurs, the dates take
> on '20' as the century value if you read values back from the Variant.
>
> I could probably fix this by storing DateValues in a Double, but I'm
> wondering if the problem can be resolved in any other way, or if this is an
> 'official' problem.
>
> Any help will be much appreciated,
>
> Thanks,
>
> Tim Foster.
>


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

What do you mean by "reading dates into variants"? If you have string that
contains a date and asign the string to a variant variable the variant
variable should contain data of the string sub-type not of the date
sub-type.

If the conversion from string to date sub-typed variant is correct I don't
beleive the will change by storing it a variable. The problem could only be
in the conversion routine. I don't know of any built in conversion routines
that convert four digit years wrong, and any routine that converts two
digit years is a potential Y2K problem. How exactly are you converting the
strings and what does the strings look like?

	Christer Romson

Tim Foster:
> After some testing in a VB4 16-bit application, I'm fairly positive there
> is a problem reading dates into Variants (VB seems to be trimming the
dates
> to Short Format), and so when the Year 2000 rollover occurs, the dates
take
> on '20' as the century value if you read values back from the Variant.

Tim Foster wrote:

>After some testing in a VB4 16-bit application, I'm fairly positive there
>is a problem reading dates into Variants (VB seems to be trimming the dates
>to Short Format), and so when the Year 2000 rollover occurs, the dates take
>on '20' as the century value if you read values back from the Variant.

I think you worry too much.

What you are looking at is the PRINTOUT FORMAT of the date, not the
actual date itself. Try using Format$() to get proper 4-digit years.

Internally, VB stores dates as day numbers (since 1900 or something),
with fractional parts for hours/minutes/seconds. One hour is 1/24
(~0.04167). See VB help, DateSerial(), for some more info. Just for fun,
try printing the result of applying CDbl() on a date.

As long as no part of your program actually depends on the date as a
string, with the year in two digits, you should be pretty safe. I just
hope the Access stores the dates properly.

HTH,
Bart.

Access stores Date/Time fields as floating point numbers, with the date
as the integer portion, and the time as the fractional portion. Dates are
stored as the number of days from December 1, 1899 (I think). VB handles
dates and times the same way.

Year 2000 compliance is actually a non-issue.... you just have to be
sure that your code can handle a short date format. (The most common
way is that if the Year of the short date is less than "1935", then add
100 to it before you do anything else. Long format dates do not present
a problem.

Enjoy!

Flewis


Tim Foster <TimF@Romtec.co.uk> wrote in article
<01bfa79b$a1ea0060$03ef98c3@novix>...
> Can anyone help provide information on what the status of Year 2000
> compliance is concerning VB3 and VB4 16-bit apps (using Access 2
> databases).
> 
> After some testing in a VB4 16-bit application, I'm fairly positive there
> is a problem reading dates into Variants (VB seems to be trimming the
dates
> to Short Format), and so when the Year 2000 rollover occurs, the dates
take
> on '20' as the century value if you read values back from the Variant.
> 
> I could probably fix this by storing DateValues in a Double, but I'm
> wondering if the problem can be resolved in any other way, or if this is
an
> 'official' problem.
> 
> Any help will be much appreciated,
> 
> Thanks,
> 
> Tim Foster.
> 

The documented base date is December 30, 1899.

Yeah, it's interesting to think about *when* there *would* be a
problem.  Since it's stored as a double, you need to think not only
about how *large* a number can be stored (about 1.80E308, according to
the docs), but *to what accuracy*.  Now, the mantissa has 52 bits, so we
could accurately represent:

 2^52 days = 2.50E15 days = 1.23E13 years (from the base date)

But what if we wanted accuracy to the second?

 2^52 seconds = 2.50E15 seconds ~ 143 million years (from the base date)

Let me know if I made a mistake!  If MS doesn't have this fixed in about
140 million years, I'm gonna start worrying...

Flewis wrote:
> 
> Access stores Date/Time fields as floating point numbers, with the date
> as the integer portion, and the time as the fractional portion. Dates are
> stored as the number of days from December 1, 1899 (I think). VB handles
> dates and times the same way.
> 
> Year 2000 compliance is actually a non-issue.... 
[cut]

Many thanks to all who have given pointers for this query.

Cheers,

Tim.