The About Visual Basic review of The Visual Basic 2005 Cookbook notes that we're fortunate here to have a real expert in dates and times in the person of frequent contributor, Peter Zilahy Ingerman, PhD. We don't normally get into the depths of specific detail in articles featured here because, like the VB2005 Cookbook, our articles are written for more general audiences.
I decided that this would be a unique opportunity, however, so I asked Peter if he would take a look at just this one chapter from his expert's perspective. The goal here is to give all of us insight into what kind of problems you're likely to run into if you do need to approach the absolute cutting edge in your programming. "Good enough" just isn't good enough for some programming but how many of us have been required to write code that was completely precise? This article will give you a feeling for what that actually involves and lets you know how much a book like the VB2005 Cookbook, or any book written for a general audience, can help.
My conclusion is that when you really need expertise, you're going to have to find someone like Peter.
The goal of this article is not to throw rocks at the VB2005 Cookbook. As I discussed the article with Peter through emails, he asked me to make certain it was clear, in Peter's words, that "I really do like the style of the book, and have learned several things just by skimming through it!" You're certainly not going to find a better explanation of how to code dates and times using VB.NET at your local bookstore.
The good news is that VB.NET 2005 has some pretty impressive globalization capability. Peter pointed out that:
"VB 2005 allows the use of several other calendars. The Chinese Lunisolar calendar, the East Asian Lunisolar calendar, the Hebrew calendar, the Hijri calendar, the Japanese calendar, the Japanese Lunisolar calendar, the Julian calendar, the Korean calendar, the Korean Lunisolar calendar, the Taiwan calendar, the Taiwan Lunisolar calendar, the Thai Buddhist calendar, and the UmAlQura calendar are all listed under System.Globalization namespace."
I wouldn't have known what names to use for them. (And the VB2005 Cookbook doesn't tell you anything about that either.) Pretty impressive!
As Peter notes:
"The authors do not state explicitly that the calendar in question to which they so blithely refer is the Gregorian calendar. The Gregorian calendar came into existence on 1582 October 15. It was defined by Pope Gregory XIII (hence "Gregorian") in Inter Gravissimas. So the first issue is that any date prior to 1582 Oct 15 is necessarily proleptic."
I had to look up the word, "proleptic" too.
Peter's analysis of Section 7.2, "Accessing the System's Time Zone" is a good example of one major category of problem if you have to code a program that is completely accurate. Peter points out that:
"Time Zones, per se, are not calendar-dependent, but are date-dependent. The precise placement of the lines separating time zones has changed several times, so that the time zone that applies to a given geographic location may well be different for different dates. No mention is made of this, so it appears that the authors are presuming the time zones that apply at the present date."
Peter further notes that:
"This section also mentions Daylight Saving Time. This is simply not to be trusted without extensive experimentation. Not only do the rules for DST change from country to country, they change over time within a country. ... some states (e.g. Arizona, Hawaii) chose not to observe DST, and other states (notoriously Indiana) made it literally a local option, possibly varying from town to town."
To give us a feeling for the size of the job, Peter helpfully listed the changes that DST has had in the US:
- No DST prior to 1918
- 1918, started Mar 31, ended Oct 27
- 1919, started Mar 30, ended Oct 26
- 1920 through 1941, rules are irregular and varied from place to place
- 1942, started on Feb 9, continued to 1945 Sep 30
- 1946-1961, no DST
- 1962-1973, started last Sun in Apr, ended last Sun in Oct
- 1974, started Jan 6, ended Oct 27
- 1975, started Feb 23, ended Oct 26
- 1976-1986, started last Sun in Apr, ended last Sun in Oct
- 1987-2006, started first Sun in Apr, ended last Sun in Oct
- 2007-????, started 2nd Sun in Mar, ended 1st Sun in Nov
The point here is that if, for some reason, you had to write a program that would accurately report the time for dates in the past, you would have to account for these. If the requirement was for accurate times in specific locations in Indiana. Well ... Peter said that Indiana accounted for a lot of aspirin sales to calendricists. And he also said that if you're dealing with other countries and cultures, there are other, potentially even more baffling problems to deal with.
