On Thu, 12 Feb 2009, Randy Portnoff wrote: Hi Randy,
> No, I am not aware of a database that stores time zone with the date/time > value. I agree with Viktor - The date/time value stored in the database > must be timezone independent (ie. UTC 0). Then, the app can set some value > (eg. environment var) to align any date/time values read from the database > with the user's timezone (this should happen automatically at the RDD > level). So, all date/time values in memory (including the current record > buffer) will be adjusted for the current timezone while date/time values in > the database will not. The implementation should be a little bit different. The timezone part should be used only for formatting strings when they are shown in human readable form if the julians part gives valid date to not convert time diff values. But I see two problems with such conversions: 1. It will be necessary to hardcode TZ tables in Harbour source code for each countries and years. It's not job for single developer because it may not have enough knowledge about rules used for time conversions and summer/winter time offsets in all countries in the world in all past years. Now we have problem with collecting CPs files for different counteries what seems to be much easier job. We can try to extract this information from some other projects, f.e. GLIBC sources but I do not know how big the full list is and how big overhead it may cause. For such TZ updating we have to know the exact rules and any static _SET_UTC_OFFSET will not help because today in Poland we use CET (Central European Time) but on the last Sunday of March we will switch to CET (Central European Summer Time) and I do not wont to see in browser that on March 27 I started my job at 9:00 AM but one record down on March 30 I begin to work at 10:00 AM. We have to implement full conversion rules so we will know that in Poland in year 2009 on March 29 the time zone is swiched at 02:00 UTC+0100 2. The second problem is compatibility with other tools. What will happen if some other xbase compilers does not make the same conversion when DATETIME is stored in DBF and Harbour application shares DBF table with VFP program? Or what will happen if other ADS clients does not make the same and they share tables with ADS RDD? It's easy to resolve such problems for single application which works only in strictly defined and well know for programmer countries in given period. Just simply programmer can hardcode all necessary conversions and does not need any additional support from HVM which sometimes can even make things harder to resolve. My personal opinion is that the worse possible choice will be implementing sth partially because later it will be very hard to revert or even fix sth due to backward compatibility which will be necessary to support values already stored in different data base systems. So now I'm interesting how it looks in other RDBMs. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
