Hi Przemek,
> > 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) Okay I understand, in order to know this rule, you must know at least the Country code. Too bad. This system sucks badly. #if OFF And we didn't even want to deal with working days, now this system, at least in my country is even worse. Almost impossible to properly deal with it. #endif > 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. Okay, I understand what you mean. Time to sleep for me now, good night for all in our TZ :) Brgds, Viktor
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
