Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VFP Issue with date selection 1/1/25 returns 1/1/1925 1

coorsman

Technical User
Nov 25, 2008
1,112
US
Hi All,

We have some old programs written in VFP 9.0 SP2 and when a date > 12/31/24, say 01/01/2025 in the date dialog screen the program is returning an error can't find date 1/1/1925.

I saw posts about adding a century settings in windows with no results.

Any ideas would be greatly appreciated,

Thanks,
coorsman!
 
One thing to check is the SET ROLLOVER setting. If you have the source and can recompile, you can change that to something higher. You might be able to change it via a CONFIG.FPW file, if the program does not then override it.
 
For cases of short dates I have programmed a ROLLOVER setting that rolls with the time, i.e. to YEAR(DATE())%100+/-offset. But for sake of no problems with dates, SET CENTURY ON and don't work with short dates, it's just stupid since we had the Y2K problem that should be in any programmers mind to not spare 2 digits here.
 
Just to be clear, the correct syntax is:

Code:
SET CENTURY TO c ROLLOVER y

where c is the century and y is the rollover year.

This only applies for dates that are entered with a two-digit year. The command takes precedence over SET CENTURY ON/OFF.

Mike
 
Hi,

You may also want to check your windows settings - see below (W10 Pro) - and/or in VFP the SET SYSFORMATS command

hth

MarK

RollOverSettings.jpg
 
Last edited:
Mike, the precendence is not hindering you to first assign a ROLLOVER and then SET CENTURY ON. If you then convert short date strings, the rollover year is still in effect, i.e. SET CENTURY ON does not reset the rollover year. What offfset you need depends on what dates you can enter. Birth dates, for example should always be past dates, except perhaps for predicted date of birth within 9 months from now. Well, but any planning dates, appointments, etc are of course usually future dates. Therefore the offset you set depends on your needs, but you can set it, even when you decide to finally SET CENTURY ON. SET("CENTURY",2) will also still show you the rollover year as one proof of it not being reset to default or inactivated.

For demonstration purposes:
Code:
Set Date American
Set Century To 19 Rollover 75
Set Century On
? Set("Century",2)
? Ctod("01/01/25")
? Ctod("01/01/75")
? Ctod("01/01/90")
Set Century To 19 Rollover 90
Set Century On
? Set("Century",2)
? Ctod("01/01/25")
? Ctod("01/01/75")
? Ctod("01/01/90")
The rollover century and years are still in full effect, even if you set CENTURY ON after setting the rollover mechanism. That's what makes the precedence unimportant.

The problem of 25 being interpreted as 1925 instead of 2025 seems to me a fixed setting of the Rollover century and year that was okay at the time it was established, but wasn't introduced in a danmically way adapting to the current year, as you surely want a current year short date to convert to the current century.

While I recommend SET CENTURY ON, you still can have a ROLLOVER year (and century) defined so your short date string conversion (for data entry works, for CSV import, etc). Ultimately, avoid any short dates, anyway. While you have a way to nudge them to the right century when knowing whether they should be past, future or current year, it's not giving you a chance with historical dates more than 100 years ago or future dates more than 100 years into the future. While you don't plan 100 years into the future, usually, there are people older than 100 years and the number of them grows. History also doesn't shorten ever, so for documentation purposes you want to be able to specify all dates of the past. and also display the century to know what dates we talk about in case of a year like 92, whether it's 1992 or 1892 or even 1492.

I'm not sure SET SYSFORMATS ON "imports" the Windows setting into VFPs Rollover concept. Worth a try to have influence from outside, it won't help, if what I assume is causing the problem, a fixed setting somewhere in the code, in the worst case, unconfigurable and not able to be influenced by neither Windows ssettings nor config.fpw or other configuration data, INIs etc. So you can try and get lucky, if that helps, it's worth doing, considering how little effort it is, but in the end you might need hands on the source code to fix this.
 
Last edited:
Foxpro has always had problems with ambiguous dates.
Not only Foxpro. A short date simply is ambiguous, there's no hidden compressed side information about the century. It only seems logic a 25 date in the year 20205 should be interpreted as 2025.

That's not automatic, when you know how the rollover mechanism works. It's still easy to use the rollover mechanism in a danymioc way that lways will turn the current year to be in the current century. From that perspective VFP has an instrument to deal with the ambiguity, you just have to know it and you might expect other programming languages or applications dealing better with this, automatically. I think you can easily find examples of other software always expecting 19 as the century until the year 2000 came along and reuired a software update. Ultimately the problem is best solved by including the century and avoiding short dates overall.

Whether it's Britiish, American or anything else also doesn't fix the century part of the problem. And you can set the order to British using SET DATE TO DMY. Besides, the Vritish setting is completely separate to century on or off. Neither British, American or other countries set the year to be 4 digits, only the CENTURY setting does. See for yourself:
Code:
Set Century Off
Set Date BRITISH
? Date()
What you state BRITISH is solving is both the date part ordering and the century. It's not, the only other thing besides the DMY order it sets is the separator being the slash, but it neither effects the CENTURY nor the HOURS of the day 24 vs AM/PM. All the country names map to one of DMY or MDY, as no country does YMD or something lilke that, as far as I know. If you think that makes all settings in one go, you have false assumptions.
 
Last edited:
Hi

Chriss

I'm not sure SET SYSFORMATS ON "imports" the Windows setting into VFPs Rollover concept.

Yes it does. But it has some other gotchas

From Hacker's Guide 7
Help states that when SYSFORMATS is set on, you can use the following SET commands to override the Windows settings: SET CENTURY, SET CURRENCY, SET DATE , SET DECIMALS, SET HOURS, SET MARK TO, SET POINT, and SET SEPARATOR. Well, most work as you'd expect: After you SET SYSFORMATS ON, if you issue a SET command to override a setting, the data displays with the overridden format and the corresponding SET() function returns the overridden value (the one you just set it to). Not so with SET CENTURY and SET MARK. They properly pick up the Windows settings when SYSFORMAT is set ON. However, issuing a SET CENTURY or SET MARK does not override the formatting in SYSFORMATS, but the SYS() function returns a value that claims it does.

But it's very challenging to work in a system where you cannot determine the current settings. Generic date-parsing routines will have to be revised to more carefully manipulate the date setting, not to depend on switching and restoring SET DATE. (Hint: If the setting of SYSFORMATS is ON and the DATE is SET to SHORT, you need to preserve and restore SET MARK TO and/or turn on and off SYSFORMATS to parse the date.) Routines to automatically size a text box to fit the date cannot depend on SET("CENTURY"). A routine that sets data session-scoped commands (as all of these are) to the default data session settings cannot always determine what these commands are set to. This command is a good idea; we'll be pleased when CENTURY and MARK are as functional as the rest.
ExampleSET SYSFORMATS ON
* In the Control Panel, set the short date to 'M/d/yy'
SET CENTURY ON
? SET("CENTURY") && "ON"
? DATE() && Yields a date in MM/DD/YY format.
hth

MarK
 
I have to check that. What I know is that SET SYSFORMAT is copying several Windows settings into FoxPro settings, at the point you issue SET SYSFORMATS ON. Afterwards settings can be overridden.

Let me check this...
You're right that SET MARK doesn't work, but when you additionally SET DATE <<Country>> the MARK setting is overridden, too. It doesn't suffice to do one of them, it doesn't matter in which order you SET MARK and SET DATE <<Country>>, as long as you have matching settings, ie the MARK is really the character used in the country, after both are done the mark is according to the country setting.

But it's also true that not only MARK can't be overriden, it's not the only exception. When changing the digit grouping character from . to , or ' that reflects in VFP immediately. I assume this is a change that happened with Windows 10 or 8 perhaps. Quite sure it wasn't that way in Vista. For now it seems when you SET SYSFORMATS ON you mostly subscribe to what the system setting is, even when it changes afterwards.

You can still get the old behavior or the behavior I know, if you SET SYSFORMATS ON and then OFF right after that. The settings are then still system settings and OFF doesn't revert them back to what you had before ON, but you can override any setting as you want to override it from system defaults, which might be necessary for things like CSV imports to work.

Still the original problem was about the century, not the order of month and day and not about the MARK setting. It's still interesting and I learned something from that. It's weird to me, but the way it is both simple models of SYSFORMATS switching beteween VFP internal and system settings or only copying them at the point of ON are wrong, obvioulsy. I suggest you experiment with this, as it's not as simple to give sample code without knwing your Windows settings and even harder to set them with Windows API or WMI to show the effects.

I conclude that I will recommend the pattern to SET SYSFORMATS ON and then OFF again as a default to have the best of both worlds, i.e. let the user configure certain settings as they like or need them in Windows and accpt them, but also staying in control as necessary to do correct data imports, for example, after which you can also go back to Window settings, so they play the major role, still. It's not at all known how that's done in coorsman application, when 25 is converted to 1925, I assume that the developer only once thought about a rollover setting working at the time of establishing it and not caring about how this will break in 2025.
 
Last edited:
Hi

Chriss

It's not at all known how that's done in coorsman application, when 25 is converted to 1925, I assume that the developer only once thought about a rollover setting working at the time of establishing it and not caring about how this will break in 2025.

Maybe Coosmann could give us some hints or at least tell us if and how he solved the problem

MarK
 

Part and Inventory Search

Sponsor

Back
Top