Y2K-VISUALBASIC : the biggest single reason for VB's non-compliance is the use of Strings to handle dates
class-solutions.com
- So Y2K should be splattered all over PC magazines!
- What about MS products being 'Year 2000 Ready'!? Surely not all the apps written with MS development tools. It is time that Bill Gates really speaks up about this issue, as Peter de Jager has asked him to do in Datamation of August(?) 1997.
John
------------------------------------------------------------------------------------------
Because the Year 2000 problem is so easily identifiable with COBOL and because Visual Basic is such a new language, many people are under the impression that the applications written with the Visual Basic programming language are completely Year 2000 compliant. In reality, nothing could be further from the truth.
Visual Basic includes various date handling functions and procedures which are intrinsic to the language, in most cases, these functions are totally unaware of the Year 2000. In fact, because of the implicit implication that these functions will work into the Year 2000, and because of over confidence in the language, applications written in Visual Basic are probably more likely to cause problems than many other languages.
Microsoft have taken steps to correct these problems by introducing fixes to these date functions in each of the major releases.
Visual Basic version 4.0 goes a long way towards fixing the date problems and most date functions recognise the Year 2000, however, VB 4.0 will always assume the current century when entering dates so therefore processing dates across two centuries will not work.
VBA 5.0 goes even further by introducing an industry accepted technique known as windowing. This technique makes assumptions about the intended century of a two digit year. However, this solution is also flawed because the window is a fixed window which only interprets dates up until 2030. For instance, given the date "01/01/32", VBA 5.0 will assume that the intended year is 1932.
Because the majority of businesses are still using 16 bit Windows (3.1 or 3.11), this look at the language will focus on version 3.0 of Visual Basic. The innovations introduced in later versions of VB are all very exiting but the main task at hand is to serve the businesses that are looking at systems already built with Visual Basic and for the most part, those existing systems will have been built using VB 3.0.
Probably the biggest single reason for VB's non-compliance is the use of Strings to handle dates as opposed to Variants of type V_DATE (7) or actual Date data types (VB 4 & 5).
Many programmers use strings to store dates internally because there is either a general reluctance to use the Variant (based on horror stories about the bad performance of Variants), or because the programmers are simply unaware that variants can and should be used....... |
