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
>
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)
DaWorm wrote:
On Mon, Jul 25, 2011 at 11:53 AM, Mark Morgan Lloyd
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 (i.e. not subscription-onl
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-0
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
On Mon, Jul 25, 2011 at 11:53 AM, Mark Morgan Lloyd
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 (i.e. not subscription-only) but
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 tim
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,
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 bas
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 curren
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 in
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 conve
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'.
>>>
>>
>>
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.
> > 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
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 date/time
17 matches
Mail list logo