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

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

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

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

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

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

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