Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 7 of 7 total
Thread Minor DateTime issue
Fri, Nov 24 2017 11:14 AMPermanent Link

Matthew Jones

If I serialise a DateTime, and it reads from the .Net JSON the value "2017-11-24T13:29:20.4619093Z" the end result from DateTimeToStr is "24/11/2017 29:20".

It appears to be getting lost in the decimal seconds.

--

Matthew Jones
Fri, Nov 24 2017 11:22 AMPermanent Link

Matthew Jones

Matthew Jones wrote:

> If I serialise a DateTime, and it reads from the .Net JSON the value "2017-11-24T13:29:20.4619093Z" the end result from DateTimeToStr is "24/11/2017 29:20".
>
> It appears to be getting lost in the decimal seconds.

Seems to be in ISOStrToDateTime and it is internal, so hard to fix. I'm beginning to think I've had this before...

--

Matthew Jones
Fri, Nov 24 2017 1:42 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< I serialise a DateTime, and it reads from the .Net JSON the value "2017-11-24T13:29:20.4619093Z" the end result from DateTimeToStr is "24/11/2017 29:20".

It appears to be getting lost in the decimal seconds.  >>

I'm not seeing any issues here with that value.  Which browser are you seeing this issue with ?

The ISOStrToDateTime function is straight wrapper around the JS engine's date parsing, so there isn't anything that involves EWB directly with this functionality.

Tim Young
Elevate Software
www.elevatesoft.com
Mon, Nov 27 2017 6:31 AMPermanent Link

Matthew Jones

Tim Young [Elevate Software] wrote:

> I'm not seeing any issues here with that value.  Which browser are you seeing this issue with ?

Hmm, a quick test shows it working here too. I shall have to work out what is happening in the application.

--

Matthew Jones
Mon, Nov 27 2017 11:31 AMPermanent Link

Matthew Jones

Tim Young [Elevate Software] wrote:

> The ISOStrToDateTime function is straight wrapper around the JS engine's date parsing

Okay, found the issue. Hmmmmm.

procedure DebugReport(szMessage : String);
var
   szTime : String;
begin                                   
   FormatSettings.ShortTimeFormat := 'mm:ss';
   szTime := TimeToStr(Now, true) + ' ';
//...


Basically, I was changing the global format for debugging, no need for the hour, and that affected it for the display info too. I've done a custom TimeToStrEx with a passed in FormatSettings, which saves it being set up all the time too.

--

Matthew Jones
Mon, Nov 27 2017 1:31 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Matthew,

<< Basically, I was changing the global format for debugging, no need for the hour, and that affected it for the display info too. I've done a custom TimeToStrEx with a passed in FormatSettings, which saves it being set up all the time too. >>

The ISO* date/time functions are all handled by the JS engine, so none of the FormatSettings have any bearing on how they work.

Or, am I missing a step and you used the format settings to send data back to the web server that later got sent back to the client ?

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Nov 28 2017 4:21 AMPermanent Link

Matthew Jones

Tim Young [Elevate Software] wrote:

> Or, am I missing a step and you used the format settings to send data back to the web server that later got sent back to the client ?

The step missing is that it is nothing to do with what I said it was originally. I stepped into it in the debugger, and that's when I found that my code was calling the debugReport function which changed the global format settings to "mm:ss" which then made the minutes look like the hour later. It's just another case where not passing in the format causes trouble. Using a version with a persistent settings reduces the time spent filling the settings anyway, so a win (so long as one makes a TimeToStr that takes a format)..

--

Matthew Jones
Image