On Tue, 10 Feb 2009, Szak�ts Viktor wrote: > > 1) internal implementation: float point number using fractional part for > > time representation (drawback: float point side effects, ex. today+8h+8h+8h > > != tomorrow, feature: easy calculation), or julian date and milliseconds. > My vote for the latter (millisecs).
There are two things here: 1. internal representation 2. .prg level arithmetic The internal representation should be separated from user code by API functions so it will be only our own choice and we can easy change it in the future. Probably keeping internally DATE and TIMESTAMP structures compatible will simplify HVM code and we will not have introduce additional if() statements or conversions what is important for speed. In such case we should have separate member with number of milliseconds in a given julian day. Just like in xHarbour. In such way we limit precision to milliseconds but we also do not introduce sth what we will have to eliminate in the future. It's always easier to extend precision then reduce it due to backward compatibility and maybe reduced functionality. The .prg level timestamp arithmetic for me should be as closed as possible to date one. I think that the best part of xHarbour datetime implementation is the possibilities to easy replace existing date fields with datetime ones and that the whole code works in the same way, f.e.: SET FILTER TO dt - 1 >= DATE .AND. DATE <= dt + 2 works well in all combinations of DATE and DATETIME used in 'dt' and DATE. Such code also works without any modifications: SET FILTER TO date() - 7 >= SALE_DATE .AND. SALE_DATE <= date() - 1 for SALE_DATE declared as pure DATE or TIMESTAMP. Walter made it really nice. If we want to keep it then it will determinate the base value returned by TIMESTAMP1 - TIMESTAMP2 and all other calculations. It will have to be number where integer parts is julian day and fraction part is time. > > 2) does we need to include timezone into timestamp; > Yes, good question. > Probably yes, if we can implement it properly and add it to the > syntax smoothly, while avoiding any possible confusion from the > user side. The conversion between local time and UTC is a nightmare. If we want to introduce time zone to TIMESTAMP items then we will have to implement conversions tables for each countries with hard coded rules for summer/ winter time periods. In many countries such periods cannot be calculated because in each year it was government decision. Now in most of European countries it's strictly defined and can be calculated for each year from some rule, f.e. this one is for Poland: TZ="CET-1CEST-2,M3.5.0,M10.5.0" but it works only for last 15 years and if I want to converts some earlier daytime values I have to use tables with hard coded periods for summer and winter time. In GLIBC source code you can find such tables for different countries and years. Probably the only one reasonable implementation we can fully implement in core code is introducing offset to UTC time but not real timezone implementation. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
