Eike Lange wrote:

On Mon, Feb 26, 2001 at 07:04:38AM +0100, Frank Heckenbach wrote:

...

A routine to check a given date (with or without checking DayOfWeek) would be nice, and I might write it someday (too busy right now), but if you have such a routine to contribute, let me know...

We have such in our GLib-Unit, GDateValid(...). Just wait a few days :-)

I looked at it. But it operates on a different type (PGDate). Converting to and from it, and linking glib is probably much more effort than writing the function in Pascal which shouldn't take more than a few lines. (I don't mean to put down the project, but using a set of date/time routines that operate on yet another type (as if there weren't more than enough already) is probably not such a good idea unless one is porting a C program that uses glib already...)

BTW, when I looked at the unit, I saw `function GPOINTER_TO_INT(x : Pointer) : Integer;' at the end. That's very dangerous. If you have to cast between pointers and integers at all for some reason, use PtrInt or PtrCard which is guaranteed to have the same size. On some 64 bit platforms, Integer is still 32 bit and Pointer is 64 bit, so this routine is a sure way to produce invalid addresses. (I don't know if glib uses `int' where it accepts pointers, but if it does, it's not 64 bit safe, either...)

Frank

Klaus F. Østergaard wrote:

I have been looking for a lib with date calculations, and found this C/PERL lib. As I don't know anything about C and how you make C work together with GPC, could some of you please look at the lib to see if it is an easier way to get more functional lib than starting all over in pascal.

Well, it's not like starting all over in Pascal. We already have most of the functionality working (the "hard" routines, e.g. converting between broken-down time and Unix time, make use of libc routines, so we didn't have to reimplement them, anyway).

What's left to do is on the one hand a number of comparably easy things like:

- Checking that a given date/time is valid (for broken-down values; Unix time is always valid). One could do this by converting to Unix time and checking if this succeeds, but I think some libcs don't do enough error checking there. Doing it by hand, however, only requires a series of rather easy comparisons, so I think that's best to do as a plain Pascal routine...

- Incrementing date/time by intervals -- this is rather easy to do in Unix time if the interval is given in seconds .. days and in broken-down time if the interval is given in months or years. Doing it in the respective other format is then done by using the available conversion routines. Also, this can be done in Pascal, using the existing routines in the GPC unit for conversion between broken down time and Unix time.

One thing missing that isn't quite as easy to do would be parsing date/time from strings. The problem is, of course, the various date/time formats -- in fact, it's not even possible to write a general-purpose routine without getting ambiguous because things like `11/03/2001' mean different dates in different countries. OTOH, routines that only accept one particular format (I have ones for the German date/time format, and I can release them if anyone is interested) would be too unflexible for general use. So, this requires some thinking about how to do it. glibc contains two functions (strptime() and getdate() -- see the glibc manual for details) which can give us some ideas, but we shouldn't use these routines because they have strange interfaces (as the manual itself admits ;-) and they're not ISO C, i.e. probably not generally available.

http://www.engelschall.com/u/sb/download/

I think this lib contains some nice routines to convert from different date/time notations, also including different languages for text name on dayes, months, converting to and from normal date and business (year week day) format ect.

I've briefly looked at this library. Some of its functionality is already there in GPC, though with a slightly different interface (using TimeStamp rather than separate day/month/year parameters, for example), so it's not needed.

Other functionality isn't there yet in GPC and having it would certainly be nice. -- It might have useful things for parsing date/time which could be converted to or serve as the basis for a Pascal version.

I have been looking at the code my self and I think I can rewrite in Pascal, so it fits to the timestamp format.

This would be fine.

Should I write the code a stand a lone lib and sent it to Frank Heckenbach/Peter Gerwinski or just to the list and then the person that maintains the GPC unit would cut and past it into the unit?

That person would be me, so you can send it to me personally or to the list.

General-purpose things I'll add to the RTS (i.e., unit GPC) then. If there's some special-purpose stuff (like the "flight-scheduling" times Eike mentioned which I don't know anything about), I think they'll better fit in a separate unit (which we could still distribute with GPC)...

Frank