On Wed, 11 Feb 2009, Phil Barnett wrote:
Hi Phil,
>> I have no idea however, how to introduce offset in syntaxes in an elegant
>> way, especially in the fixed position format.
> I believe that the last time this came up, I pointed out that I had
> completed all the necessary julian functions in both ANSI C and Clipper
> code and have had it posted for over 10 years on The Oasis. But as far as I
> know, nobody looked at it.
I remember about it and thank you. Anyhow here they will not help us
a lot. We already have functions to manage julian dates and time
factor introduce only few additional by simple calculations.
The main problem we have now is syntax which we should use for
constant representation of timestamp (date + time) values in .prg
code.
The second one is introducing UTC offset to this value so local time
extracted on different computers in the whole world can be easy compared.
This seems to be the most problematic part because database systems
usually does not support this additional attribute so when our timestamp
value is stored and retrieve into database then information about UTC
offset is lost. I do not see any easy solution here which will work
in all cases. Probably the easiest solution is working internally on
time in UTC+0000 and only using functions to convert to local time
when values are presented. In such case we do not need any additional
member with UTC offset in hour timestamp structure.
The 3-rd problem is internal representation. In general we have two
choices here:
1. two 32bit fields for julian day and number of millisecond in this day
2. double value with julian day in integer part and time in fractional
part.
The 1-st one is faster to mange in HVM during operations on timestamp
items though a little bit more complicated (code will be longer). The
bad is that it has fixed millisecond precision.
The 2-nd one is very simple to write code (the HVM code will be a little
bit shorter) but this code will be also a little bit slower due to double
conversions. But it also has one additional feature. The precision is
variable and such type can be used to count time differences. Even if
it contain whole julian date then for julian day we need
log( date() - ctod("") ) / log(2) ~= 22
22bits. It means that we have 31 bits on IEEE758 double (53bit precision)
for time so we have ~ 25 better precision. Without julian day part, f.e.
when this type is used to count some time differences the precision is
much bigger ~100'000'000 times for single day period.
But not all systems allows to access time with better then millisecond
precision so such functionality will be dummy in some cases.
> I used these functions successfully in Time and Attendance software that
> was sold all over the US for a decade.
> The format is simple and the conversion functions are very fast.
I believe we can use them as library functions for Harbour but in
core code they will not help us too much. The timestamp value is
necessary for us if we want to easy exchange data with different
database systems or programs, use it in RDD expressions, f.e. as
filters and index key/for expressions just like now we are using
dates. The helper functions to manage timestamp value in some
different representations does not resolve all problems.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
