[fpc-pascal] Timezone information in a dataset datetime field?- updated

Mark Morgan Lloyd markMLl.fpc-pascal at telemetry.co.uk
Mon Jul 25 13:26:47 CEST 2011


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]



More information about the fpc-pascal mailing list