Hi Mindaugas,
> > Fine but I suggest to create separate function to extract number of
> > seconds from some starting day, f.e.:
> > HB_FUNC( HB_MILLISEC )
> > {
> > hb_retnin( hb_dateMilliSeconds() );
> > }
> and use it instead of seconds().
> I've looked to the source and can commit new implementation.
> hb_dateMilliSeconds() is OK, but it returns different results for
> different platforms. It's "julian milliseconds" on Windows and
> milliseconds from 1970-01-01 on Unixes.
It's not only one difference. In *nixes it's UTC time when in Windows
is local time.
The idea of hb_dateMilliSeconds() was creating function which can
return some time value measured from some some starting point which
is OS/application dependent. On some platforms it can be 1970-01-01 on
some others Julian milliseconds and on some others number of milliseconds
from application startup. On some platforms HB_LONG can be even 32bit
integer and in such case the starting point should be as close as possible
to reduce number of counter resetting (I do not think it's worth to invest
more time in other solution for such platforms).
In summary this function was designed only to calculate time difference
between two calls in single program instance on given machine.
> I think it would be good to give the same meaning for both platforms.
> Julian milliseconds is 48bit integer now. It is not far from double
> precision (52bit) and hb_dataMilliSeconds()*16 conversion to from double
> can show float point side effects. So, milliseconds from 1970-01-01 are
> better in this case, but it is a little platform oriented and will
> return negative values for birthdays of us or our fathers.
> What choice do you prefer?
We have hb_dateTimeStamp() which cab be used if you want some datetime
value calculated from comparable starting point.
But if it's not enough then we can add new function which should return
UTC time instead of local one so the result will be comparable also
between programs working in different time zones so can be used in INET
communication. Using double seems to be reasonable as holder for Julian
milliseconds. In such case we can return Julian date as integer part and
time as fractional part what will allow to keep it with a little bit
better precision if platforms allows it.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
