Hi Przemek,
> > 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. My thoughts exactly. > > 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. 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. 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. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
