Reinier Olislagers wrote:
On 25-7-2011 12:09, Mark Morgan Lloyd wrote:
Pretty much the same for PostgreSQL. I went through all this a few
months ago, and while I didn't explore data entry I found that for data
output I had to apply corrections myself although I could get properties
of the current timezone from an internal table.
In all cases the fundamental question is whether the OS has been
installed with correct notification of where it's operating, and whether
is has any mechanism to track what's going on if it's moved around.
Correct. Would you happen to have some cross platform code readily
available that spits out either:
1. Offset from UTC for a certain (historical or future) date/time
2. Timezone abbreviation suitable for inclusion in my XML export (don't
know yet what formats Access/ADO.Net/Excel/whatever needs)
... never hurts to ask, does it ;)
Indeed :-) Unfortunately not, since what I did was have a .ini-format
configuration file specifying (the current system's) lat/long and basic
timezone, and then used an SQL query to ask the database what it thought
was going on from a standard table (i.e. whether DST is currently in
operation). Using this it was trivial to plug a DST correction back into
the code, and also to display the effective timezone name. I doubt any
of this is portable since it makes a lot of assumptions about the server.
I've made a point for the last few years of having all critical machines
locked to GMT. I once found myself having to deal with three different
timezones in a forensic problem, and once is quite enough.
If GPS could be persuaded to cough up basic information about the
operative timezone in a standardised form (i.e. "you're in a country
that uses WET") it would make things much easier. Or failing that if
somebody had a comprehensive translation between lat/long and basic
timezone info, i.e. "this polygon is GMT", "this polygon is WET" and so
on; unlike transition dates etc. this wouldn't change very often.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
