InStr Question

"Rick Brandt" wrote in message
. com...
Steve Schapel wrote:
Tom Lake wrote:
... If I just give you the
digits 59
is that 1959 or 2059? You have no way to know.

Well, to be fair, in 99% of cases it is obvious from the context. So
"you have no way to know" is seldom correct.

I just find two digit years to be an ill-advised and completely
unnecessary way
to avoid TWO keystrokes.

A Date field is DATA. It should be entered and stored completely and
non-ambiguously, and a year happens to include four digits. Why not enter
4
digits? Speed? Storage? Two digit years is merely a convention and a
silly
one. We don't allow context to determine the value of any other type of
data.
Why single out dates?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com


Old habits die hard (even bad ones).

We all became painfully aware of the problem a few years ago. With the way
that life expectancy is rising this could end up being a substantial problem
for "Date Of Birth" well before we get to the next century mark.

--
Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.

I know what you are saying, Rick, and where there is a chance of
ambiguity I agree that great care should be taken to ensure accuracy.
As you know, dates are "stored completely" no matter what, so I guess I
am talking about the data entry and the display aspects. I agree that
two digit years is "merely a convention", and it is a convention I
generally choose to follow. There are many mere conventions like this,
for example using abbreviations like lbs to mean pounds. I find the
data easier to read if it isn't clogged up with unnecessary junk like
which century is being referred to. Yes, there is also a data entry
factor, for example my users would often find it simpler to enter
today's date as 1/1/6 and it then displays (in my applications, given my
domicile) as 01-Jan-06. I am not advocating that this is the "correct"
way to do it, or that others should do the same, but it works for me,
and feedback from my users supports this. I am certainly not against
you or Tom always using 4 digit years, but I was prompted to question
the "no way to know" statement.

--
Steve Schapel, Microsoft Access MVP

Rick Brandt wrote:
I just find two digit years to be an ill-advised and completely unnecessary way
to avoid TWO keystrokes.

A Date field is DATA. It should be entered and stored completely and
non-ambiguously, and a year happens to include four digits. Why not enter 4
digits? Speed? Storage? Two digit years is merely a convention and a silly
one. We don't allow context to determine the value of any other type of data.
Why single out dates?

Steve Schapel wrote:
I know what you are saying, Rick, and where there is a chance of
ambiguity I agree that great care should be taken to ensure accuracy.
As you know, dates are "stored completely" no matter what, so I guess
I am talking about the data entry and the display aspects. I agree
that two digit years is "merely a convention", and it is a convention
I generally choose to follow. There are many mere conventions like
this, for example using abbreviations like lbs to mean pounds. I
find the data easier to read if it isn't clogged up with unnecessary
junk like which century is being referred to. Yes, there is also a
data entry factor, for example my users would often find it simpler
to enter today's date as 1/1/6 and it then displays (in my
applications, given my domicile) as 01-Jan-06. I am not advocating
that this is the "correct" way to do it, or that others should do the
same, but it works for me, and feedback from my users supports this. I am
certainly not against you or Tom always using 4 digit years, but
I was prompted to question the "no way to know" statement.

I know that this is often pushed by users (God love em), but I just find it
humorous. I'll design a form where the user has to enter numerous 15 character
part numbers, 20 character serial numbers, a (how freakin long) shipping tracker
number and a few sentences of notes and then they'll ask why I make them enter
all 4 digits of the year.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Rick,

When I was referring to my users, I was thinking more of the
display/readability aspect rather than the data entry aspect. As
regards the data entry aspect, I usually teach my users that they don't
need to enter *anything* at all for the year, if it is the current year,
which it very frequently is - depending on the type of application of
course. So you would very often see my users simply typing 5/2 enter
and they end up with Access storing 38753 and their forms and reports
displaying 05-Feb-06.

--
Steve Schapel, Microsoft Access MVP

Rick Brandt wrote:
I know that this is often pushed by users (God love em), but I just find it
humorous. I'll design a form where the user has to enter numerous 15 character
part numbers, 20 character serial numbers, a (how freakin long) shipping tracker
number and a few sentences of notes and then they'll ask why I make them enter
all 4 digits of the year.

On Sat, 31 Dec 2005 16:48:26 -0500, "Randy Harris"
wrote:

We all became painfully aware of the problem a few years ago. With the way
that life expectancy is rising this could end up being a substantial problem
for "Date Of Birth" well before we get to the next century mark.

It already is a problem. My church database needed (until her passing
last Spring) to deal with one lady born in '97, and with one of her
great-great-granddaughters also born in '97.

John W. Vinson[MVP]

On Sun, 01 Jan 2006 11:31:14 +1300, Steve Schapel
wrote:

Rick,

When I was referring to my users, I was thinking more of the
display/readability aspect rather than the data entry aspect. As
regards the data entry aspect, I usually teach my users that they don't
need to enter *anything* at all for the year, if it is the current year,
which it very frequently is - depending on the type of application of
course. So you would very often see my users simply typing 5/2 enter
and they end up with Access storing 38753 and their forms and reports
displaying 05-Feb-06.

.... of 05-Feb-2006 at no cost other than an eighth of an inch of
screen space... g

John W. Vinson[MVP]

"Steve Schapel" wrote in message
...
Tom Lake wrote:
... If I just give you the digits 59
is that 1959 or 2059? You have no way to know.

Well, to be fair, in 99% of cases it is obvious from the context. So "you
have no way to know" is seldom correct.

Not with the dates I deal with!

Tom L

Randy Harris wrote:
Old habits die hard (even bad ones).

Funny. A few months ago, I did some modifications to an Access
application that I had originally built in '96 (apologies for any
ambiguity g). In the process of doing so, I noticed how ugly the 4
digit years in the dates look to me now, and I changed them all! :-)

We all became painfully aware of the problem a few years ago. With the way
that life expectancy is rising this could end up being a substantial problem
for "Date Of Birth" well before we get to the next century mark.

I can certainly see that if I had a database where the data in a date
field spanned more than 100 years, I would take a different approach in
that specific case. Just by an accident of the databases I have worked
on so far, I don't think this has ever arisen. The players in the
soccer league include young children, starting at 5 years old, but
luckily the association has a rule no players allowed over 90, so we're
safe there ;-).

--
Steve Schapel, Microsoft Access MVP

Tom Lake wrote:

Not with the dates I deal with!

Fair enough, Tom. I guess design decisions should be based on the
specifics of the project.

--
Steve Schapel, Microsoft Access MVP