I notify that synapse have some tools for timezone in synautil unit like:
{:Return your timezone bias from UTC time in minutes.}
function TimeZoneBias: integer;
{:Return your timezone bias from UTC time in string representation like
+0200.}
function TimeZone: string;
I don't know that they are
On 25-7-2011 21:48, José Mejuto wrote:
Hello FPC-Pascal,
Monday, July 25, 2011, 12:54:13 PM, you wrote:
RO Correct. Would you happen to have some cross platform code readily
RO available that spits out either:
RO 1. Offset from UTC for a certain (historical or future) date/time
RO 2.
1. Is there any way of knowing what kind of timezone a
datetime value
should be in a FPC dataset? (I suppose not...)
No, there is no way. It's always supposed to be 'local time'.
That is also what most of the underlying databases do. They store everything
in UTC and convert to local
On 25-7-2011 10:50, Ludo Brands wrote:
1. Is there any way of knowing what kind of timezone a
datetime value
should be in a FPC dataset? (I suppose not...)
No, there is no way. It's always supposed to be 'local time'.
That is also what most of the underlying databases do. They store
On 25-7-2011 11:21, Reinier Olislagers wrote:
On 25-7-2011 10:50, Ludo Brands wrote:
1. Is there any way of knowing what kind of timezone a
datetime value
should be in a FPC dataset? (I suppose not...)
No, there is no way. It's always supposed to be 'local time'.
That is also what most
Ludo Brands wrote:
1. Is there any way of knowing what kind of timezone a
datetime value
should be in a FPC dataset? (I suppose not...)
No, there is no way. It's always supposed to be 'local time'.
That is also what most of the underlying databases do. They store everything
in UTC and
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
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
Mark Morgan Lloyd wrote:
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
Reinier Olislagers schrieb:
I realize having a local timezone option will result in a hornet's nest
of adjustments for Daylight Saving Time etc... I'll try and check to see
if it is possible to specify the timezone description instead of the
offset in the export datetime field.
If so, I'll
On 25-7-2011 18:23, Jürgen Hestermann wrote:
Reinier Olislagers schrieb:
...
If so, I'll try and get timezone description from the OS...
Timezone information is not enough to get reliable dates. Dependend on
where dates origin from they can be wrong (wrong clock on computer,
wrong time zone
On Mon, Jul 25, 2011 at 11:53 AM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk wrote:
Link below looks directly relevant: it contains polygon data for each
timezone, subject to knowing the current location.
http://efele.net/maps/tz/world/
I've confirmed that files are accessible
Hello FPC-Pascal,
Monday, July 25, 2011, 12:54:13 PM, you wrote:
RO Correct. Would you happen to have some cross platform code readily
RO available that spits out either:
RO 1. Offset from UTC for a certain (historical or future) date/time
RO 2. Timezone abbreviation suitable for inclusion in my
Hello FPC-Pascal,
Monday, July 25, 2011, 6:23:21 PM, you wrote:
JH And even if dates are correctly stored in UTC it is not easy to reliably
JH get back the local time. Daylight savings were changed in the past
JH (and may also change in the future). If you have a date/time of
JH 2001-05-01
DaWorm wrote:
On Mon, Jul 25, 2011 at 11:53 AM, Mark Morgan Lloyd
markmll.fpc-pas...@telemetry.co.uk wrote:
Link below looks directly relevant: it contains polygon data for each
timezone, subject to knowing the current location.
http://efele.net/maps/tz/world/
I've confirmed that files are
On 7/25/2011 15:53, José Mejuto wrote:
Hello FPC-Pascal,
Monday, July 25, 2011, 6:23:21 PM, you wrote:
JH And even if dates are correctly stored in UTC it is not easy to reliably
JH get back the local time. Daylight savings were changed in the past
JH (and may also change in the future). If
On Sat, 23 Jul 2011, Reinier Olislagers wrote:
Hi all,
I'm busy with writing an XML export unit targeting Microsoft Access/.Net
framework (ADO.NET data access framework in particular).
Runing an ADO.NET demo program I found out that the ADO.NET variant
requires timezone info in its
17 matches
Mail list logo
