Egbert Zijlema's programming place

The author Welcome to my 'new' website. Mind the quotes: it's not really new. It just replaces my former Basic Guru pages. For several years those have been hosted by Dave Navarro, the founder of the Basic Guru site. Several programmers from Europe, the USA and Australia participated in this project, willing to share their knowledge and skill with a worldwide community of enthousiastic users of the BASIC programming language.
Unfortunately, after hurricane Charley blew over Florida – causing severe damage to Dave's office in Port Charlotte – Dave and his wife decided to leave the 'hurricane belt' and moved to Tennessee. So the site was closed by the end of March 2005. This is the place to thank my fellow programmer Thomas Gohel from Berlin, one of the former Basic Guru participants, who is willing to provide the necessary disk space on his server, in order to host (and to continue) my website under a more or less familiar name: zijlema.basicguru.eu.

As most of my fellow-programmers know, I create all my code using Power Basic's Windows compiler. It is my favorite tool now, as was their DOS-product back in 'the good old days'. I want to emphasize, however, that I am in no way affiliated with Florida-based Power Basic Inc. I'm just one of their (satisfied) customers.

One of my most significant programming tools this far is the Gregorian Calendar Library, a still growing bundle of routines to manipulate calendar dates. The main function of that bundle is a computation that converts a calendar date into an integer day number (type LONG). It fits exactly in the Gregorian Calendar, which means: day number 1 represents 15 October 1582, the official first date of our modern calendar system. In some publications day numbers from the Gregorian Calender are referred to as Lilian Day Numbers, but don't be mistaken. A Lilian Day Number is just a calculated Julian Day Number from which 2,299,160 days were subtracted. The first date in the Julian numbering system is November 25, 4714 BC, on – what is called – the proleptic Gregorian Calendar. In other words, Lilian-computations hide approximately 60 centuries of useless Julian day numbers. My Gregorian Day Number formula does not need nor uses this trickery. It has its own, genuine mathematics.

The latest version of the library – release date: September 10, 2008; timestamp 08:09 – contains a completely modified function: GregDateFormat, which processes all possible flags for the standard function GetDateFormat correctly now, including short dates. Furthermore it repairs one very old-fashioned long date format and three malformatted ones. They exist in Windows XP and as far as I was told, Microsoft did not correct them in Windows Vista, nor in Windows 7. As you might have discovered, the GetDateFormat function from the Windows application programming interface (API) returns an incomplete long date for Great-Britain and Wales and a wrong one for Catalonia (Spain). The British and the Welsh full date are returned without the day name, the Catalonian is shown with the forward slash between the elements (which is the short date separator, actually).

The Swedish full date according to Windows is an old school example. Like the British one it lacks the name of the day, although this is a very common long date element. Instead it contains the word 'den' ('the'). It may be used perhaps in official or legal papers (in sentences like: "this contract has been signed the 25th of January") but in daily use, for instance in a date as part of a newspaper's page header, you will not encounter it. Nobody knows how and where the Microsoft programmers found this old-fashioned method of writing a Swedish long date. I want to thank Gunnar Boxström from Sweden for his information on this subject. Anyway, GregDateFormat supercedes Windows' GetDateFormat and returns the correct long dates. It's all be shown in the demo file DateString.BAS.

One of the newer functions in the library is a routine to fetch an ordinal for either a given day in the month or a calendar date passed as a Gregorian Day Number. This is, in fact, the opposite of finding those calendar dates, commonly referred to as the "first, second, third, fourth or last whateverday of the month", for instance Thanksgiving Day, the fourth Thursday of November (in the USA). Keep in mind that there is only one routine now for both, the first through fourth and the last whateverday of the month. Simply pass 5 as the ordinal to get the last whateverday of the month, which is not necessarily the fifth. Also new is that you may omit the year parameter. In that case the routine will find the first occurrence of the day you're looking for, either this or next year.

Another new function will be demonstrated in the routine SameDay.BAS. It returns a Gregorian Day Number for a 'same' day either in the previous year or in the next year. As you might have discovered, your birthday always occurs one or two days 'later' in the following year. I mean: when it was on a Monday this year, it will fall on a Tuesday next year; or even on a Wednesday when a leap year is involved. This shift is caused by the length of a full year, that is either 365 or 366 days and, unfortunately, not 364 (52 weeks exactly). So, in case you are looking for a corresponding Monday in either last or next year, you should subtract or add 364 days. Simple principle used in the new function SameDayAltYear. It takes 4 params: year, month, day and a byte value that should either be 0 (last year) or 1. The function calculates the Gregorian Day Number for the given date and subtracts or adds 364.

The archive (GREGORIAN.ZIP) offers the following content:

GREGORIAN.INC: the library functions.

DATESTRING.BAS: shows how GregDateFormat repairs the British, Welsh, Catalonian and Swedish date bug.

DAYDIFF.BAS: returns the number of days between 2 calendar dates.

DAYOFWEEK.BAS: demonstrates how to calculate a date's day of the week (Monday - Sunday).

DAYSINMONTH.BAS: returns the number of days in a given month (Jan.= 31, Feb. = 28 or 29, etc.).

GREG2DATE.BAS: demonstrates how to convert a Gregorian Day Number to a calendar date.

GREGDEMO.BAS: demonstration of several routines from the Gregorian Date Library.

MONTHDAYFORMAT.BAS: shows how to display a calendar date without the year and the day name.

ORDINALS.BAS: will show a couple of ordinal-related functions.

SAMEDAY.BAS: returns the GDN for the "same" date either previous or next year.

WEEKNUMBER.BAS: demonstrates how to calculate ISO-proof week numbers (see: next issue).

Recently I had to rewrite the week number routine in the above mentioned calendar library, due to the fact the function GetLocaleInfo from Windows' application programming interface (API) does not always return a correct first week of the year, especially for some countries in the European Union. This is very strange, because at the same time Windows offers a month calendar control (SysMonthCal32) with correct week numbers. Is this a known or a neglected issue in Redmond?

One of my latest projects was an article about creating card games, using Windows' default playing cards library. To be honest, I did not do it all by myself. Borje Hagsten from Sweden has been a great help, especially in the field of 'drag and drop'. The article has been published in The Power Basic Gazette and is still available for download: here. You need to click on gaz043.txt to read it. Of course, there's a code sample as well. You may either download it from Power Basic or from my site. Important note for XP-users: in case you want to use animated card backs (not supported in Windows XP) you can download the matching library from Microsoft's download site. Note that the library is packed in a file named games.exe. The only file you need to extract is cards32.dll.

It's very easy now to check if your next birthday-party will coincide with Easter Sunday or Pentecost. For that purpose I've added a special menu to my wellknown Easter Date Calculator. Actually this little program was my very first project for Windows. It was an application originally being written for DOS. After purchasing PBWin, I decided to port it to the Windows platform, which was not easy. Not because of the calendrical calculations, since they did not change (apart from a few minor corrections). It was the Windows environment or Graphical User Interface which was such a different and sometimes difficult matter. Text controls, for instance, appeared to be too narrow to display the beautiful (but long) names for Easter and Pentecost as used in Cataluña (Spain). Another problem was caused by going international. While running in Spain, my proggie knew very well it had to 'speak' Spanish. But after being installed on a Mexican computer, for instance, it fell back to English, as it did in all the Spanish speaking countries of Latin America, to mention a few unexpected hick-ups. I've solved those problems now. And last but not least I got the opportunity to add Cymraeg (Welsh). I want to thank John Krijnen, Simon Morgan and Chris Holbrook for their contributions.

Egbert's programming place