Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread Possible ISOStrToDateTime Problems
Thu, Sep 3 2015 11:36 AMPermanent Link

Mark Brooks

Slikware

Avatar

The API that I work with returns timestamps in ISO format so Tim's recent addition of ISO format datetime handling has been very welcome. However I am finding that I get different results for the "hour" element using different browsers. I have a simple function (below) that takes an ISOStr and returns a formatted string for display purposes. The output is 1 hour adrift on Chrome and Safari but correct on IE and Edge. I'm wondering if there's some form of issue with BST (British Summer Time) but can't locate the ISOStrToDateTime code to check (guess it's an internal part of the compiler)

function MCBPrettyISODateTime(const AISOStr: string): string;
var
 D: DateTime;
begin
 D := ISOStrToDateTime(AISOStr);
 Result := DateTimeToStr(D);
end;

Any guidance would be much appreciated
Mark
Thu, Sep 3 2015 11:54 AMPermanent Link

Raul

Team Elevate Team Elevate

On 9/3/2015 11:36 AM, Mark Brooks wrote:
> The API that I work with returns timestamps in ISO format so Tim's recent addition of ISO format datetime handling has been very welcome. However I am finding that I get different results for the "hour" element using different browsers. I have a simple function (below) that takes an ISOStr and returns a formatted string for display purposes. The output is 1 hour adrift on Chrome and Safari but correct on IE and Edge. I'm wondering if there's some form of issue with BST (British Summer Time) but can't locate the ISOStrToDateTime code to check (guess it's an internal part of the compiler)

Is your API returning UTC or local time ? (is the are Z after time or
any other indicator).

I'd suspect it's daylight savings related but some samples on what raw
data coming in looks like likely would help Tim also to narrow this down.

Raul



Thu, Sep 3 2015 12:03 PMPermanent Link

Mark Brooks

Slikware

Avatar

>>Raul wrote:

>>Is your API returning UTC or local time ? (is the are Z after time or
>>any other indicator).

>>I'd suspect it's daylight savings related but some samples on what raw
>>data coming in looks like likely would help Tim also to narrow this down.

Hey Raul

Format is like this 2015-09-03T16:48:50.5200000

Mark
Thu, Sep 3 2015 12:25 PMPermanent Link

Raul

Team Elevate Team Elevate

On 9/3/2015 12:03 PM, Mark Brooks wrote:
> Format is like this 2015-09-03T16:48:50.5200000

OK - so this is simple local time (not UTC) and i can confirm that i'm
seeing the same difference here :

- IE/Firefox sees the date as : 1441313330520 (4:48pm on June 3rd 2015)
- Chrome however converts to : 1441298930520  (12:48pm on June 3rd 2015)

basically Chrome assumes it's UTC while IE/FF assume local time zone.

Appears it's a known problem on how to interpret local date :
http://stackoverflow.com/questions/28618296/iso-8601-date-js-interpretation-difference-ie-ff-versus-chrome

I peeked underneath the EWB skirt and ISOStrToDateTime does use
Date.parse internally (and if SO is to be believed then that's the issue).

if you have an option of having the API return either UTC data or
specifying a time zone then that should be a useable workaround (you
could append the time zone yourself but then you need to know what it
actually is in terms of time daylight savings or not).

Raul
Thu, Sep 3 2015 3:03 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Mark,

<< Format is like this 2015-09-03T16:48:50.5200000 >>

That's going to be an issue without a time-zone specification.  As Raul indicated, EWB uses the browser's built-in ability to parse the ISO 8601 date-time strings, and there are some differences in how they're handled if you don't specify a time zone offset (or Zulu for UTC).

Tim Young
Elevate Software
www.elevatesoft.com
Image