Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 4 of 4 total
Thread Suggestion - Dates Again....
Fri, Jul 5 2013 8:11 AMPermanent Link

Walter Matte

Tactical Business Corporation

Additional Data Type     ->   dtDateTimeNoOffset

I know the consensus here in another thread was for dtDateTime - to have no TZ Offset and introduce a new data type dtDateTimeOffset for TZ Offset.

But - I am guessing it would be easier to add a new type dtDateTimeNoOffset - so that existing code need not be changed.    If you could add this to the EWB IDE Compiler/Client Side (Load and Commit ... etc) - people like me who have written their own Server can easily handle this for the date fields we need transferred without TZ Offsets.

Tim - you could deal with this later in the EWBSrvr ? .....

Walter
Mon, Jul 8 2013 2:32 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Walter,

<< I know the consensus here in another thread was for dtDateTime - to have
no TZ Offset and introduce a new data type dtDateTimeOffset for TZ Offset.

But - I am guessing it would be easier to add a new type
dtDateTimeNoOffset - so that existing code need not be changed.    If you
could add this to the EWB IDE Compiler/Client Side (Load and Commit ...
etc) - people like me who have written their own Server can easily handle
this for the date fields we need transferred without TZ Offsets.

Tim - you could deal with this later in the EWBSrvr ? ..... >>

The issue here is that the server side does not necessarily "know" the same
information about the dataset that the EWB side does.  The EWB side has the
benefit of knowing that a date/time column is defined a certain way because
you define it as such using EWB.  The server side has to derive this
information from the database engine, and many database engines will not
support TZ indicators for data types (EDB and DBISAM do not, for example).

So, in the next build I'm introducing a breaking change that will, by
default, treat date/time columns as having *no* TZ alterations, meaning the
values will come across exactly as they are stored in the database.  There
will be an additional property for date/time columns that will control if
you want to turn on TZ alterations on both the dataset definition side
(server) and the EWB side (client).


Tim Young
Elevate Software
www.elevatesoft.com
Mon, Jul 8 2013 4:53 PMPermanent Link

Walter Matte

Tactical Business Corporation

>>The issue here is that the server side does not necessarily "know" the same
>>information about the dataset that the EWB side does.  The EWB side has the

I understand - but in my case - the Server does know - since I wrote it.  I would make sure which dates get TZ and which dates do not.

>>So, in the next build I'm introducing a breaking change that will, by
>>default, treat date/time columns as having *no* TZ alterations, meaning the
>>values will come across exactly as they are stored in the database.  There
>>will be an additional property for date/time columns that will control if
>>you want to turn on TZ alterations on both the dataset definition side
>>(server) and the EWB side (client).

Just so I understand, will the additional property be on the Dataset Column, so that some dates can be designated TZ and some dates not TZ?

Walter
Thu, Jul 11 2013 12:08 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Walter,

<< I understand - but in my case - the Server does know - since I wrote it.
I would make sure which dates get TZ and which dates do not. >>

Yes, but with the automatic dataset handling, this is most certainly *not*
the case.

<< Just so I understand, will the additional property be on the Dataset
Column, so that some dates can be designated TZ and some dates not TZ? >>

No, on the dataset as a whole.  Again, most database engines do *not*
support TZ-sensitive date/time columns, and there's no way for a developer
to set a column-specific property for the back-end datasets in EWB, so the
property has to be a dataset-wide property.

Tim Young
Elevate Software
www.elevatesoft.com
Image