Hi Przemek,
> Not only DATEs but also TIMESTAMPs. Even if we'd fully honor TZ > signature in our internal representation (this is quite easy) Yes, I meant timestamp of course. > then it does not resolve the problem how to restore it when TIMESTAMP > value is exchange between Harbour and different data base systems. Since there is no standard ways to do that, we cannot do else than leave this to the app developers. For example I store the TZ in a location/host table, so it's basically a per site global app setting [ I know this has it's disadvantages, but so far this was enough ], in the database there the dates are stored after converted to UTC-0000. > For DBFs I can implement new field type which can hold timezone or > UTC offset. But what to do with closed systems like ADS or different > SQL RDBMS? For my own use in such cases I use in application only UTC+0000 > values. But for such usage I do not need any additional support from HVM. Same here. Basically a TZ is just a "N", 6, 2 (or maybe even 1 is enough), number. Core Harbour can help to do some required calculations. Through functions and maybe through a Set(). Anyhow this doesn't really influence the core/HVM timestamp implementation, as these are just making calculations on regular timestamps, nothing more. > Just simply I'm using function which returns UTC time instead of local one. Exactly. > I'm really interested if some RDBMSes already supports TZ signature or > UTC offset or at least UTC+0000 flag. I don't know, probably there are, but I expect a beautiful chaos in this area, especially when it comes to details :) For sure normal .dbf, .csv doesn't have such means, so we have to adapt. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
