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.
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
On 25-7-2011 11:51, Ludo Brands wrote:
Runing an ADO.NET demo program I found out that the ADO.NET
variant requires timezone info in its date/time fields. In a
sample export I did, it is set to my timezone (UTC+2 at this moment).
ADO.NET exports timezones but it isn't required for import.
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
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
14 matches
Mail list logo