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)
"Jorge Aldo G. de F. Junior"
wrote in message
news:CAAHHabS9aUe9gwyNjkve-XVXsRyf2UPsArh6=fsdpgokugj...@mail.gmail.com...
> Some time ago someone asked for a library able to do network calculations.
>
> Here is something that might evolve into such library :
>
> Function NetMaskToHostMask(NetMas
Some time ago someone asked for a library able to do network calculations.
Here is something that might evolve into such library :
Uses
Classes,
SysUtils,
StrUtils;
Type
TNetworkIP = Record Case Mode : Boolean Of
True : (IP1, IP2, IP3, IP4 : Byte);
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
>
> In the meantime, I've finished the ADO.Net export functionality.
>
> I'd appreciate further test reports!
>
I'm getting an "http://www.w3.org/2001/XMLSchema:element not taken into
account in this context" (freely translated from French) error.
Fixed this by adding between and
One other c
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,
> > After these changes, import in access 2002 and 2010 is ok. Multiple
> > field indices is working also?
>
> It should be as it now takes the fields property (a semicolon
> delimited list of fields according to the help) & replaces ;
> with a space, which is the format that appears in my test
On 25-7-2011 17:37, Ludo Brands wrote:
>
>> I did see one improvement in your 2010 export: descending
>> indexes are supported as opposed to Access XP I'll tweak
>> the format to spit that out & see if Access XP can read it...
Still to do...
> Tested the creation of index info from MySQL S
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
> I did see one improvement in your 2010 export: descending
> indexes are supported as opposed to Access XP I'll tweak
> the format to spit that out & see if Access XP can read it...
>
>
Tested the creation of index info from MySQL SQLQuery and found some issues.
Line 222:
if IsPu
On 7/25/2011 11:17 AM, Marco van de Voort wrote:
In our previous episode, Lee Jenkins said:
M:\lazarus_current\lazarus\fpc\2.5.1\bin\i386-win32>fppkg install embweb
The FPC Package tool encountered the following error:
[embweb] Package fcl-web is not available
M:\lazarus_current\lazarus\fpc\2.
In our previous episode, Lee Jenkins said:
> M:\lazarus_current\lazarus\fpc\2.5.1\bin\i386-win32>fppkg install embweb
> The FPC Package tool encountered the following error:
> [embweb] Package fcl-web is not available
>
> M:\lazarus_current\lazarus\fpc\2.5.1\bin\i386-win32>fppkg list
> Name
On 25-7-2011 13:31, Ludo Brands wrote:
>> So you're saying that this:
>> 2011-07-22T15:00:00+02:00
>> can be simplified to this: 2011-07-22T15:00:00
>> ?
> It does. It uses TZ to convert if specified but assumes local time if not
> specified. Tested this when importing access 2010 data.
Ok, that
> So you're saying that this:
> 2011-07-22T15:00:00+02:00
> can be simplified to this: 2011-07-22T15:00:00
> ?
> I'll amend my simple ADO.Net test program to import XML and
> see what it does.
>
> If that is true, it would save a huge amount of aggravation.
>
It does. It uses TZ to convert if
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 11:57, Ludo Brands wrote:
>>> That is also what most of the underlying databases do. They store
>>> everything in UTC and convert to local time. Only for those that
>>> support "timezoned" field types (fe. oracle timestamp_TZ) you can
>>> specify a timezone when entering data. MySQL
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 impo
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
> I realize having a local timezone option will result in a
> hornet's nest of adjustments for Daylight Saving Time etc...
As per previous messages, why bother? It is not a requirement for importing
data in ADO.NET.
Ludo
___
fpc-pascal maillist -
> > That is also what most of the underlying databases do. They store
> > everything in UTC and convert to local time. Only for those that
> > support "timezoned" field types (fe. oracle timestamp_TZ) you can
> > specify a timezone when entering data. MySQL fe. doesn't
> have support for this.
> 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. Since the main
concern is to export
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
29 matches
Mail list logo
