Kim,

There are two issues here:

1) Daylight savings time, and

2) The fact that you're expecting time values to observe the same behavior as date/time or date values with respect to 1).

Here's what I'm seeing with the server set to UTC and the client set to EST (*with* DST in effect), all of which is correct:

Server:

Date column: 2017-10-06 on server, 2017-10-05 in browser = correct (time is 0:00:00, so date gets rolled back 4 hours based upon EST DST)

Time column: 17:13:11.950 on server, 12:13 PM in browser = correct (time is rolled back 5 hours based on EST, can't compute DST because there isn't a date component)

Date/Time column: 2017-10-06 17:13:11.950 on server, 10/6/2017 1:13 PM in browser = correct (time is rolled back 4 hours based upon EST DST)

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>>There are two issues here:
Date column: 2017-10-06 on server, 2017-10-05 in browser = correct (time is 0:00:00, so date gets rolled back 4 hours based upon EST DST)

Time column: 17:13:11.950 on server, 12:13 PM in browser = correct (time is rolled back 5 hours based on EST, can't compute DST because there isn't a date component)

Date/Time column: 2017-10-06 17:13:11.950 on server, 10/6/2017 1:13 PM in browser = correct (time is rolled back 4 hours based upon EST DST)<<

Tim,
If I do this will it work?
Column in the EDB is set to Date. I have a variable MyDate set as TDateTime;
MyDate := StrToDateTime(01/01/2017 05:00:00);
Would the Time be saved in the EDB  so it would show the right date in a Grid or do I have to save all data and time only fields as time stamps then extract the data or time and load the grid manually?

Kim

Kim,

<< Would the Time be saved in the EDB so it would show the right date in a Grid >>

The issue isn't whether the time is saved with the date or not (it is).  The issue is whether a date/time has enough information to determine DST, and time values by themselves *do not* have enough information (see below).  In general, if you need to localize date-times, then you should always use combination date-time types (timestamp in EDB and other databases) so that you don't lose any information and the localization can proceed without issue.

Further complicating matters is that EWB doesn't control how such values are initialized/stored in the database, so it's certainly possible to have date values in a database that have odd time portions that aren't visible.  It all depends upon how the date/time is stored and retrieved.  With EDB, you're pretty safe because EDB stores dates as signed 32-bit integers, times as signed 32-bit integers, and date/times (timestamps) as signed 64-bit integers, so it never has any issue with "phantom" date or time portions.

Examples:

If you issue this call in EWB:

MyDate:=Date();

the time is initialized to midnight (12:00:00 AM) on the current date.

For times, however, the situation is a little different.  With this call:

MyTime:=Time();

the date is initialized to the current date and current time.  Localizing such a time value will cause weird results because a) when you display the time, you won't be able to see the date portion, and b) the date portion is fixed to a specific date that really has no relation to the time value other than being the value that was current at the moment that the time was retrieved/assigned.

Tim Young
Elevate Software
www.elevatesoft.com

Ok, I have a program where a user can select which date they want to have a pickup.

How would I save this as a timestamp to get the right date when I save it and retrieve it to EST.
Would I be able to save it as MyTimeStamp := '01/01/2017 04:00:00'

Kim

Kim,

<< Ok, I have a program where a user can select which date they want to have a pickup.

How would I save this as a timestamp to get the right date when I save it and retrieve it to EST.
Would I be able to save it as MyTimeStamp := '01/01/2017 04:00:00' >>

If you're only interested in the date, and you *don't* want the date to change due to localization of the time portion of the date, then you should turn *off* localization for this dataset on both ends and just show the date as-is.

As a matter of fact, it's probably a good idea for *EWB* to do this for you.  This discussion has led me to believe that localization of dates (as opposed to times or date/times) is of limited use and only really confuses the issue.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>>If you're only interested in the date, and you *don't* want the date to change due to localization of the time portion of the date, then you should turn *off* localization for this dataset on both ends and just show the date as-is.

As a matter of fact, it's probably a good idea for *EWB* to do this for you.  This discussion has led me to believe that localization of dates (as opposed to times or date/times) is of limited use and only really confuses the issue.<<

Unfortunately I have customers in all the US time zones and I have time in the same tables. I will have to find another way. If I save everything to EST will it localize the PST?

Kim

Kim,

<< Unfortunately I have customers in all the US time zones and I have time in the same tables. I will have to find another way. >>

Times are problematic because of the lack of a corresponding date (apart from the arbitrary date [see below] that was used when the time was initialized), which *can* (but not necessarily will, depending upon the date used) mess up DST adjustments. But, apart from that, there is no problem with using localized times on both ends, *from the perspective of EWB*.

The issue that you run into is what I indicated before: the database reading/writing may involve different ideas of what the date portion of a time looks like.  For example, when you read a time value from any database via the TDataSet component (or a descendant component like the TEDBTable component), Delphi will initialize the date portion of the time to a special "DateDelta" value, which corresponds to 12/30/1899 (which I'm sure you've seen before).  Obviously, using this date portion will result in some weird DST adjustments compared to the current date, and make any type of localization difficult because of the date portion used.

So, what's the solution ?  The solution is to *always* use date/time, or timestamp in EDB, values.  This will ensure that there aren't any arbitrary date portions being used, and you can always see the full value.  You don't have to show the date portion to the end user, if you don't want.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>>So, what's the solution ?  The solution is to *always* use date/time, or timestamp in EDB, values.  This will ensure that there aren't any arbitrary date portions being used, and you can always see the full value.  You don't have to show the date portion to the end user, if you don't want.<<

I don't see a way to only show the date or time portion of a timestamp.

I will have to load the grid my self instead of a connection to the dataset and convert date and time to the local time my self.

One day when you have lot of time maybe we can have a DataFormat property in the Grid Column, this way I could have a Time Stamp, but format it to only show the Date or Time, it could also be used for float and double like always show 2 digits after decimal point.

Kim

Kim,

<< I don't see a way to only show the date or time portion of a timestamp. >>

You can use the OnGetText/OnSetText event handlers for this purpose, and you only need to define them in one place (for the column in question):

https://www.elevatesoft.com/manual?action=viewevent&id=ewb2&comp=TDataColumn&event=OnGetText
https://www.elevatesoft.com/manual?action=viewevent&id=ewb2&comp=TDataColumn&event=OnSetText

Tim Young
Elevate Software
www.elevatesoft.com