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

[coorsman]

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!

 

[GTGeek88]

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.

 

[GriffMG]

Set CENTURY may also be significant

 

[BugZap13]

Century rollover docu

 

[Chris Miller]

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.

 

[Mike Lewis]

Just to be clear, the correct syntax is:

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

 

[mjcmkrsr]

Hi,

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

hth

MarK

 

[Chris Miller]

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:

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.

 

[Gary Sutherland]

Foxpro has always had problems with ambiguous dates. I use SET DATE BRITISH to force dd/mm/yyyy display format.

 

[Chris Miller]

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:

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.

 

[mjcmkrsr]

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.

Example	SET 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

 

[Chris Miller]

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.

 

[mjcmkrsr]

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

 

[coorsman]

Hi Everyone,

I was reaching out for some assistance. Unfortunately, it's still not functioning correctly, and I'm not the original programmer for this system. The software, developed over 20 years ago, has multiple versions deployed and customized at different sites. Although I have all the original code and VFP program installed and running, my knowledge of VFP is limited.

Over the past few years, I've been transitioning most sites and new installations to .NET. I was hoping there might be an easy setting adjustment within Windows that could resolve this issue, as re-compiling all the programs isn't feasible at this point. I have most of the modules re-written in .NET except for some custom sites, but it seems we've finally been bitten by this millennial bug.

If anyone has any other suggestions or ideas, I'm open to trying them.

Thank you for your help.

TIA,
KB - coorsman.

 

[Tore Bleken]

You have already been presented with the right answer. And may I say, the only practical solution.

You need to add one or two lines. Both lines involve Set Century. More details at https://www.vfphelp.com/vfp9/_5wn12pevx.htm

If you need personal help, email me at <firstname>@<lastname>.no

 

[Chris Miller]

If you have the source code and VFP available, you can use the IDE tool of a project search, namely the menu item "Code References" in the Tools menu of VFP, to search for ROLLOVER in the whole project. If I assume correct you will find a setting that stops working this year, unfortunately, and could only solve that by recompilation. You might be able to find the code in the binary EXE and change it there, too, when we'd be able to tell you to which byte values SET CENTURY...ROLLOVER compiles to, I think that could be a solution, but before guessing it exists at all, it would be best to find it and know the "exact wording" used in the code.

If you already tried the advice given regarding Windows settings, it seems the software does never SET SYSFORMATS ON and so you could have no influence from outside, there's no way to enforce that. So the only alternative to Windows settings becomes a (hopefully documented) configuration availble by INI files or config data of any kind, The VFP typical config.fpw is not the only configuation that can be programmed, i.e. the developer is free to implement any mechanism from registry values over ini files, xml, whatever as they are all standards in themselves. A config.fpw could only be uesd to configure some VFP environment settings, of which the rollover year is none, so it won't help you to introduce it.

The vfp EXE might react to a config.fpw file you create in the same directory as the EXE and you could try it with the only line in it being SYSFORMATS=ON and then retry influencing the application with Windows settings. I'm not even sure SYSFORMATS is an item usable in the config.fpw.