Hi Przemek,
Yes, I see your point - Make all date/time values (DB and in memory)
UTC 0 and only adjust what the user sees. This will have to happen at
the application level since there are many UI possibilities (eg. DOS,
Windows, Web). Perhaps add a special mask to be used with the
Transform() function or maybe an extra param in the DtoC() function.
With respect to Harbour knowing what the timezone is - Could that not
come from the O/S? In Windows, this can be obtained using the
GetTimeZoneInformation() API - I imagine something similar is
available in other O/S also. However, in the case when Harbour is
used as a server program (eg. CGI web app), the time zone bias would
need to be overridden at the PRG level since it would have to be set
based on the user's time zone and not where the server is installed.
Regards,
Randy.
At 02:17 PM 2/12/2009, you wrote:
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
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
