On Thu, 12 Feb 2009, Szak�ts Viktor wrote: Hi Viktor,
> > 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. > Oh, you mean TZ passed as some sort of standard string > value? > IMO, no way should Harbour try to handle these. Let's > call it rather UTC offset, and let's make it a simple numeric > value in minutes or hours. Sorry but it's not enough. > To handle any more details than that it's a perfect job > for a 3rd party lib. Updating it here regularly is a nightmare. > > 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 > Okay, that's what I wrote above. I was thinking of UTC offset the > whole time, but were writing TZ, sorry. But without information about TZ rules we will not be able to present valid local time. In Poland 17:00 UTC+0000 today means 18:00 (CET) but on March the 30 the same time (17:00 UTC+0000) will be: 19:00 (CEST) Without real timezone information we will not be able to present valid local time. In both cases we extract from data base 17:00 UTC+0000. Where we will find information that we should present it in local time as: 18:00 or 19:00. Without full timzone tables I see only one solution. Make conversion from UTC to local time using OS function. Most of modern OS-es usually supports such conversions at least for one country set for given system. But here we will have other problem which should be resolved. DATE() functions returns local date on UTC+0000 one. If we want to keep internally TIMESTAMP values in UTC+0000 then we should make conversion to local time (add UTC offset) before we make any comparison or calculations between DATE and TIMESTAMP value. We probably cannot change DATE representation now due to backward compatibility so (though I do not like it) maybe we should keep in HVM TIMESTAMP value as local time and makes conversions only when we exchange data with external systems, f.e. data base files. Anyhow it's internal implementation detail which can be changed at any time and which will not be visible for Harbour users. The public Harbour API should hide it so it's not a problem we have to discus here. If we agree that we store TIMESTAMP values always as UTC+0000 in external systems then we will have yet another problem which should be resolved when TIMESTAMP value is extracted. We should not make conversion to local time if TIMESTAMP value contains time period not a whole date, f.e. one hour "01:00:00.000". I do not want to see the situation when this one hour is converted to two hours because I run my program in UTC+0100 timezone. Without UTC flag stored in the table we have to introduce some hacks to cover such situations. F.e. we can define that if TIMESTAMP value is smaller then STOD( "00000101" ) then it's time period not exact date and time so it should not be converted but taken directly as UTC+0000. It will reduce the maximal range of time periods to 1721060 days what gives ~4712 years and few days. IMHO it's big enough period in most of cases. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
