DateSerial

[Jeremy Wallace]

I have some code that uses DateSerial to populate a couple of text boxes on
a form. I was doing some testing this afternoon and found that I get funny
values if the year supplied is 99. 98 works fine. 04 works fine. 1999 works
fine. 100 works fine. But 98 gives a funny value. Anyone have thoughts on
why, or how to re-form the dateserial call to deal with this?

Here's some results from the immediate window:
?(DateSerial(98 , 12+ 1, 1)) - 1
12/31/1998

?(DateSerial(99 , 12+ 1, 1)) - 1
-657435

?(DateSerial(10 0 , 12+ 1, 1)) - 1
12/31/100

?(DateSerial(04 , 12+ 1, 1)) - 1
12/31/2004

Here's the line I use in code:
Me!txtEnd = DateSerial(intY earEnd, intMonthEnd + 1, 1) - 1

For the values above that give legit dates, it works fine, of course. But
for 99, I get 12/30/1899. Clicking in the field gives 12:00:00 am. It looks
to me as if it's coming up with some equivalent to zero, but I can't figure
out why. I suppose I could deal with error checking at the control level,
but I was hoping to avoid that (the code is currently in a function that
gets called from several places).

Jeremy

--
Jeremy Wallace
AlphaBet City Dataworks
http://www.ABCDataworks.com

[David W. Fenton]

"Jeremy Wallace" <ab**********@A lphaBetCityData works.com> wrote in
news:tI******** ************@sp eakeasy.net:

I have some code that uses DateSerial to populate a couple of text
boxes on a form. I was doing some testing this afternoon and found
that I get funny values if the year supplied is 99. 98 works fine.
04 works fine. 1999 works fine. 100 works fine. But 98 gives a
funny value. Anyone have thoughts on why, or how to re-form the
dateserial call to deal with this?

Here's some results from the immediate window:
?(DateSerial(98 , 12+ 1, 1)) - 1
12/31/1998

?(DateSerial(99 , 12+ 1, 1)) - 1
-657435

?(DateSerial(10 0 , 12+ 1, 1)) - 1
12/31/100

?(DateSerial(04 , 12+ 1, 1)) - 1
12/31/2004

Here's the line I use in code:
Me!txtEnd = DateSerial(intY earEnd, intMonthEnd + 1, 1) - 1

For the values above that give legit dates, it works fine, of
course. But for 99, I get 12/30/1899. Clicking in the field gives
12:00:00 am. It looks to me as if it's coming up with some
equivalent to zero, but I can't figure out why. I suppose I could
deal with error checking at the control level, but I was hoping to
avoid that (the code is currently in a function that gets called
from several places).

Er, why are you passing 2-digit years?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Jeremy Wallace]

Just testing. If it weren't for this oddity I could pretty much get away
without forcing four-digit entry in this text box--I'm okay with the
windowing that goes on with two-digit years. But this thing with the 99 is
strange. Have you seen it before?

--
Jeremy Wallace
AlphaBet City Dataworks
http://www.ABCDataworks.com
"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@24. 168.128.86...

"Jeremy Wallace" <ab**********@A lphaBetCityData works.com> wrote in
news:tI******** ************@sp eakeasy.net:

I have some code that uses DateSerial to populate a couple of text
boxes on a form. I was doing some testing this afternoon and found
that I get funny values if the year supplied is 99. 98 works fine.
04 works fine. 1999 works fine. 100 works fine. But 98 gives a
funny value. Anyone have thoughts on why, or how to re-form the
dateserial call to deal with this?

Here's some results from the immediate window:
?(DateSerial(98 , 12+ 1, 1)) - 1
12/31/1998

?(DateSerial(99 , 12+ 1, 1)) - 1
-657435

?(DateSerial(10 0 , 12+ 1, 1)) - 1
12/31/100

?(DateSerial(04 , 12+ 1, 1)) - 1
12/31/2004

Here's the line I use in code:
Me!txtEnd = DateSerial(intY earEnd, intMonthEnd + 1, 1) - 1

For the values above that give legit dates, it works fine, of
course. But for 99, I get 12/30/1899. Clicking in the field gives
12:00:00 am. It looks to me as if it's coming up with some
equivalent to zero, but I can't figure out why. I suppose I could
deal with error checking at the control level, but I was hoping to
avoid that (the code is currently in a function that gets called
from several places).

Er, why are you passing 2-digit years?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

"Jeremy Wallace" <ab**********@A lphaBetCityData works.com> wrote in
news:AJ******** ************@sp eakeasy.net:

Just testing. If it weren't for this oddity I could pretty much
get away without forcing four-digit entry in this text box--I'm
okay with the windowing that goes on with two-digit years. But
this thing with the 99 is strange. Have you seen it before?

No, because I never allow 2-digit years, always forcing 4-digit.

Why?

Because the windowing behavior is dependent on a DLL that is not
part of the Access application I ship, and because on some OS's
(Win2K, WinXP, at least) it can be overridden by the end user to be
some behavior you don't expect.

Since I can't know what the window will be, I can never depend on
it.

To me, depending on the year window to interpret 2-digit years
correctly is like turning on AutoCorrect in a combo box -- you're
turning control over to a subsystem whose behavior you cannot
predict.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Jeremy Wallace]

I agree that it's turning control over to a subsystem I can't control, but
in this application there's no data entry, it's just reporting on data in
another database, so there can't really be any long-lasting impact from
putting in a wrong number--you'll just retrieve the wrong set of records.
All I'm looking for out of the windowing feature is that it be
consistent--that the user knows why it's doing what it's doing, or can
figure it out.

I am also really curious about this behavior.

--
=============== ==
Jeremy Wallace
AlphaBet City Dataworks
ABCDataworks dot com
"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@24. 168.128.78...

"Jeremy Wallace" <ab**********@A lphaBetCityData works.com> wrote in
news:AJ******** ************@sp eakeasy.net:

Just testing. If it weren't for this oddity I could pretty much
get away without forcing four-digit entry in this text box--I'm
okay with the windowing that goes on with two-digit years. But
this thing with the 99 is strange. Have you seen it before?

No, because I never allow 2-digit years, always forcing 4-digit.

Why?

Because the windowing behavior is dependent on a DLL that is not
part of the Access application I ship, and because on some OS's
(Win2K, WinXP, at least) it can be overridden by the end user to be
some behavior you don't expect.

Since I can't know what the window will be, I can never depend on
it.

To me, depending on the year window to interpret 2-digit years
correctly is like turning on AutoCorrect in a combo box -- you're
turning control over to a subsystem whose behavior you cannot
predict.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[CDB]

AD99 is outside the scope of the Microsoft date-handling functions. But the
13th month IS in scope - Jan 1st, 100. One day before that is out of scope
again.

?(DateSerial(99 , 12+ 1, 1)) - 1
-657435

This is AD100 - within the scope.
?(DateSerial(10 0 , 12+ 1, 1)) - 1
12/31/100

A simpler expression is:
?(DateSerial(10 0 , 12+ 1, 0))

Day 0 is the day before day 1.

Clive
"Jeremy Wallace" <ab**********@A lphaBetCityData works.com> wrote in message
news:AJ******** ************@sp eakeasy.net...

Just testing. If it weren't for this oddity I could pretty much get away
without forcing four-digit entry in this text box--I'm okay with the
windowing that goes on with two-digit years. But this thing with the 99 is
strange. Have you seen it before?

--
Jeremy Wallace
AlphaBet City Dataworks
http://www.ABCDataworks.com