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]

Re: DateSerial

"Jeremy Wallace" <absolutejunk@A lphaBetCityData works.com> wrote in
news:tIudnYG5Co rQ29vdRVn-iQ@speakeasy.ne t:
[color=blue]
> 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).[/color]

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]

Re: DateSerial

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" <dXXXfenton@bwa y.net.invalid> wrote in message
news:Xns94A1A9A 29AF0Bdfentonbw aynetinvali@24. 168.128.86...[color=blue]
> "Jeremy Wallace" <absolutejunk@A lphaBetCityData works.com> wrote in
> news:tIudnYG5Co rQ29vdRVn-iQ@speakeasy.ne t:
>[color=green]
> > 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).[/color]
>
> 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[/color]

[David W. Fenton]

Re: DateSerial

"Jeremy Wallace" <absolutejunk@A lphaBetCityData works.com> wrote in
news:AJGdnSNi0b hYq9rd4p2dnA@sp eakeasy.net:
[color=blue]
> 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?[/color]

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]

Re: DateSerial

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" <dXXXfenton@bwa y.net.invalid> wrote in message
news:Xns94A284C D3CA26dfentonbw aynetinvali@24. 168.128.78...[color=blue]
> "Jeremy Wallace" <absolutejunk@A lphaBetCityData works.com> wrote in
> news:AJGdnSNi0b hYq9rd4p2dnA@sp eakeasy.net:
>[color=green]
> > 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?[/color]
>
> 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[/color]

[CDB]

Re: DateSerial

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" <absolutejunk@A lphaBetCityData works.com> wrote in message
news:AJGdnSNi0b hYq9rd4p2dnA@sp eakeasy.net...[color=blue]
> 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[/color]