2/29/00 Not!

2/29/00 Not!

Post by Nelson Ramo » Sat, 22 Jan 2000 04:00:00



I have a workload reporting database that uses FM 4.0, v3. I tried today to
enter data in a date field for 02/29/00 and it would not take the date.

As a test, I created a standalone database with only 1 text and 1 date field
and once again 02/29/00 or 02/29/2000 would not be accepted.

I'm running Win95 and my system date/time clock, as well as the rest of my
applications like Outlook, all show this as a valid date. Am I not doing
something right?

I tried going through Filemaker support but it's almost not possible to get
through without leaving a credit card for tech support.

 
 
 

2/29/00 Not!

Post by Paul E. Est » Sun, 23 Jan 2000 04:00:00




> I have a workload reporting database that uses FM 4.0, v3. I tried today to
> enter data in a date field for 02/29/00 and it would not take the date.

> As a test, I created a standalone database with only 1 text and 1 date field
> and once again 02/29/00 or 02/29/2000 would not be accepted.

> I'm running Win95 and my system date/time clock, as well as the rest of my
> applications like Outlook, all show this as a valid date. Am I not doing
> something right?

> I tried going through Filemaker support but it's almost not possible to get
> through without leaving a credit card for tech support.

Uncheck use system formats from the format menu, I think FM thinks you are
in a different region. Alternately enter your date as 29/02/2000 or
whatever format the region your file is on is set to.

Paul E.

 
 
 

1. BUG: 2/29/00 invalid date?


[originally posted to comp.lang.pascal.delphi.misc]

I believe that it does -- and a very, very important point is that the user
can not easily be sure whether it does or not.

The time has come for all of us to begin conditioning users to enter four
digit dates.  At the very least, we want to display the dates immediately
after entry in an acceptable date format.

For example, I particularly like the way that MS-Access has done it.  They
allow you to enter a date as short as "26" (interpreted as the 26th day of the
current month) to "February 22, 1985."  The date input is interpreted
according to a consistently-applied set of rules.  Date *output* formatting
can use a *different* set of rules, so that our "26" would immediately be
redisplayed as "August 26, 1996" as soon as the user tabs out of the field.

So, IMHO, there are two separate issues in "the year 2000 problem" as it
affects us all.  The first would be how dates are stored in the databases;
which is generally not an issue at all provided that we use Date/Time types
and not character.  The second is how our users enter and see the date
values... to remove the -question- of whether a date is 1900 or 2000.

I also believe that we will need to design into our programs and reports,
certain "reasonableness checks" that look for dates circa 1900 and rejects
these as unreasonable if they are found.  This is also a good place to apply
database field-validation rules as are available in our respective database
systems.

/mr/

2. File Printing

3. Problem with 02/29/2000

4. Request For Database with Java application book.

5. Problem starting as service. FIXED

6. 2/29/2000 Problem?

7. SQL Server 7 and 16bit ODBC

8. Argh!!! NOT NOT NOT...Help with Access SQL

9. not null column during CTAS(not null definition did not come across)

10. why NOT IN cluase not working?

11. SQLOLE ole object could not be registered , class not registered (80040154)

12. I can not connect to my SQLServer - encryption not supported