Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Year 2038 bug
Message
De
06/01/2000 22:33:14
 
 
À
06/01/2000 22:29:57
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Titre:
Divers
Thread ID:
00314146
Message ID:
00314289
Vues:
28
>>>It appears Visual Foxpro is not 2038 complaint. Unix systems that store the date in 32 bits are prone to this, and it appears some VFP stuff is, too. I found this out, because my system somehow got set to 2057, and I tried to build setup files-- MAKECAB crashed numerous times(every time). I narrowed it down to a 2038 problem. Should this naturally fix itself as 64-bit systems become mainstream, or does MS have to change the way they hold a date? Should I inform MS, or are they well aware?
>>
>>That's not a VFP problem. VPF fully supports years up to 9999. The problem is coming from the MAKECAB utility. Microsoft is pushing the Visual Studio installer. You should take a look at it. It's pretty cool and MUCH easier to use than the setup wizard. You can get information from the VFP home page.
>
>bytes 1-3 of the dbf header are the last updated date in the form
>
>byte 1 is the number of years since 1900
>byte 2 is the month
>byte 3 is the day of the month
>
>if foxpro uses unsigned characters for the byte, it fails in 2156
>if foxpro uses signed characters for the byte it fails in 2027
>
>I suspect that the file format will be modified before either of these dates.

I note that the base for the year rolls forward to the current century automatically, therefore your your conclusion is most likely. I'll return to my Sierra Nevada Pale Ale.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform