Klaus F. Ãstergaard wrote:
I would like to help improving GPC with time and date procedure and functions.
I have been looking into the GPC unit and found this:
{ Is the year a leap year? } function IsLeapYear (Year : Integer) : Boolean; asmname '_p_is_leap_year';
{ Returns the length of the month, taking leap years into account. } function MonthLength (Month, Year : Integer) : Integer; asmname '_p_month_length';
Are you calling a c routine(asmname '_p_.......' ) ? if so why if in the unit gpc-bp the function is programmed in pascal?
These `_p_' asmnames are basically a kludge to prevent linking problems when a user's unit contains routines of the same name. When GPC will support qualified identifiers, this won't be necessary, but for now, we try to do this in the units shipped with GPC, to avoid problems there (and failing to do so in the System unit has already lead to problems, see the parallel thread `assert' -- what a timing ;-).
The asmnames are not really related to whether the routines are written in C or Pascal.
BTW, the gpc-bp unit is a GPC compatibility unit for BP (which is very incomplete, BTW). It is not the implementation of the "real" GPC unit. That is in several files in the p/rts/ directory in GPC source distributions (and the compiled version is in libgpc.a). If you don't have the GPC sources, don't worry -- you can write them in a separate unit, and I can move them to the RTS later.
If I want to help improve on the date time routines, what would the strategy be to maintain portability?
I think that getting time from the system should be kept in C.
All other calculation on date and time should be done in pascal, in the gpc- or a new datetime-unit, what ever that fits best into maintaining the compiler.
Exactly.
Is LeapYear (f) calculate day of week (f) formating date/time to strings
We have these already. Is there anything wrong with them?
validate date (f) validate time (f)
Yes, we'll need them.
calculate day of year (f) calculate week of year (f)
Actually, I've written those already, but they were hidden within the FormatTime function. I'm now extracted them as separate functions (GetDayOfYear etc.), so they're there now.
For the week of year, however note that there are several definitions for which I've provided routines: One can start with the first Sunday/Monday in the year as the first week and days before that day are in "week 0" (of course, starting with any other weekday is also conceivable, but probably not very common). Then there's the ISO week, where "week 1" is the first week which has the majority of its days in the given year, so the first/last few days of a year may belong to the last/first week of the previous/next year (that's what you sometimes find printed on calendars). Therefore the latter routine returns two values, the ISO week and the year in which the ISO week is (which is usually, but not always, the same as the year given).
By the way in timestamp definition: Seconds is 0 .. 61 shoulden it be 0 .. 60 (as 0..59 gives a minuet) and 59 + 1 leap second gives 60?
Somewhere (but I don't remember where) I found a mention of 0 .. 61, apparently allowing for two leap seconds in a row. I'm not an expert on these matters, and if someone who is confirms that this can't happen, we can change it to 0 .. 60. (Otherwise, 0 .. 61 shouldn't hurt, either.)
Frank