type TimeStamp = {@@packed} record DateValid, TimeValid : Boolean; Year : Integer; Month : 1 .. 12; Day : 1 .. 31; DayOfWeek : 0 .. 6; { 0 means Sunday } Hour : 0 .. 23; Minute : 0 .. 59; Second : 0 .. 61; { to allow for leap seconds } MicroSecond : 0 .. 999999 end; Is there a function/procedure that calculates the DateValid and TimeValid. Does it proof the DayOfWeek? What is leap seconds and how does one calculate with leap seconds? Does any one know of standard libs/rutines for doing calculations/manipulations with the timestamp, like calculating the day of the week or finding time between two timestamps, with corrections to the diffent length of months ect. Thanks, Klaus
Klaus F. Ãstergaard wrote:
type TimeStamp = {@@packed} record DateValid, TimeValid : Boolean; Year : Integer; Month : 1 .. 12; Day : 1 .. 31; DayOfWeek : 0 .. 6; { 0 means Sunday } Hour : 0 .. 23; Minute : 0 .. 59; Second : 0 .. 61; { to allow for leap seconds } MicroSecond : 0 .. 999999 end;
Is there a function/procedure that calculates the DateValid and TimeValid. Does it proof the DayOfWeek?
Not yet. Currently, routines that set the time (e.g. GetTimeStamp) just set them to True after storing the current date/time and to False if there was any error. 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...
What is leap seconds and how does one calculate with leap seconds?
Leap seconds are introduced once every few years (I think) to keep the official time in sync with the motion of the earth. Unless you're into very high precision timing operations, you shouldn't have to worry about them. It's just that some moments in time have to be represented with second values > 59. Note, many (most?) OSs don't support leap seconds at all (especially on PCs -- their timers are far more inaccurate, anyway).
Does any one know of standard libs/rutines for doing calculations/manipulations with the timestamp, like calculating the day of the week
GetDayOfWeek (unit GPC).
or finding time between two timestamps, with corrections to the diffent length of months ect.
Convert to Unix time (number of seconds since midnight UTC 1970-01-01 which is much more convenient to calculate with), do your calculations, convert back. (Despite its name, Unix time is supported on all platforms, not only Unix.) See UnixTimeToTimeStamp and TimeStampToUnixTime. E.g., I use the following routine to increment by a number of days, leaving the time unchanged. This takes into account possible DST changes (otherwise you could just increment by multiples of 24*60*60 seconds, but when crossing the beginning/ending of DST, this would be off by 1 hour, and might even land in the wrong day if the time was within the last/first hour of the day). procedure IncDateDays (var Date : TimeStamp; Days : Integer); var DateSave : TimeStamp; begin DateSave := Date; Date.TimeValid := True; Date.Hour := 12; { to avoid DST problems } UnixTimeToTimeStamp (TimeStampToUnixTime (Date) + Days * 24 * 60 * 60, Date); Date.TimeValid := DateSave.TimeValid; Date.Hour := DateSave.Hour; Date.Minute := DateSave.Minute; Date.Second := DateSave.Second; Date.MicroSecond := DateSave.MicroSecond end; To output date/time in (almost) any conceivable format, see FormatTime (in recent GPC versions). Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
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 :-) Eike
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 -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
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. 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. Hope this can help improve GPC kind regards, Klaus F. Ãstergaard ----- Original Message ----- From: Frank Heckenbach <frank@g-n-u.de> To: <gpc@gnu.de> Sent: Saturday, March 03, 2001 9:00 AM Subject: Re: Timestamp format and calculations?
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
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
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 -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
participants (3)
-
Eike Lange -
Frank Heckenbach -
Pernille Bech & Klaus F. Østergaard