Eivind,

<< Then I started looking in to timezones and went through different timezones on my computer. Both Mac and Windows. What I found out was that all timezones from UTC to UTC -12 generated good time values (Correct time values). From UTC to UTC +12 generated messed up time values. Please have a play around with browser versions and timezones with my project and see if you can replicate the same I found. >>

Beautiful, thanks, that helps a lot.

I will try to take a look this evening or early tomorrow and see what I can find.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim

I was just wondering if you had any luck tracing down the issues with time on Chrome? I'm kind of starting to feel the pressure from my customers as they are unable to use their favourite browser.

Until next build or 3.0 is there a hot fix I can implement?

Thanks for any info

Br
Eivind

Eivind,

<< I was just wondering if you had any luck tracing down the issues with time on Chrome? I'm kind of starting to feel the pressure from my customers as they are unable to use their favourite browser. >>

No, nothing yet, but I haven't had much time to look at it.  I'm doing an EDB 2.29 release today and tomorrow, and then I will take a look as part of the new EWB 2.06 build.

Tim Young
Elevate Software
www.elevatesoft.com

Thanks for the info Tim! Hopefully some fixes in the the next build then

Eivind,

Okay, I'm looking into this again before I release the 2.06 B19 build, but I'm not having much luck reproducing what you're seeing.  This is what I see on Chrome 70 on Windows (7, but it shouldn't matter):

-5 GMT

00:00
04:15
05:04
08:00
08:45
16:00
16:28
19:20

Most other time zones, range from +1 GMT to +10 GMT work fine, also, with some time zones resulting in a five minute swing in the positive direction (don't ask me why), and the +3 GMT (Moscow) and +4 GMT (Abu Dhabi) time zones resulting in some slightly odd results:

+3 GMT

23:30
03:45
04:34
07:30
08:15
15:30
15:58
18:50

+4 GMT

23:41
03:56
04:45
07:41
08:26
15:41
16:09
19:01

So, there's some form of drift taking place during the time zone conversions in the browser, but I'm not sure what's causing them.  EWB simply uses the raw time values as-is, and does nothing but call browser JS API methods for converting them to a string representation.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

Eivind,

<<<<Okay, I'm looking into this again before I release the 2.06 B19 build, but I'm not having much luck reproducing what you're seeing.  This is what I see on Chrome 70 on Windows (7, but it shouldn't matter):>>>>

Hi Tim. I have sent you an email with a link to a video showing you my issues and how to trigger them. Also, in the end I show you that changing from time to datetime datatype solves the problem, but displays a data value off course. The video can be found here: https://www.dropbox.com/s/0h2yflkt75p0f28/EWB_Time_Chrome.avi?dl=0

Thanks

Eivind

Eivind,

Per-email:

I did some more research, and the issue looks like it is with a new way of dealing with time zone offsets:

https://medium.com/@rikdriever/javascript-date-issue-since-chrome-67-50aa555799d0

which implies that Chrome (and other browsers) are going to take into account the *year* of the date when determining time zone offsets.  So, I'm going to have to figure out what to do about this, and it's probably *not* a simple fix.  We use raw date-time values (integers) with no date portion (zero for the date portion) for time values, so this is going to pose a really big problem for existing applications, especially since not all *existing* browsers behave the same way.

Tim Young
Elevate Software
www.elevatesoft.com

<<<<<<<<<<<<Tim Young [Elevate Software] wrote:

Eivind,

Per-email:

I did some more research, and the issue looks like it is with a new way of dealing with time zone offsets:

https://medium.com/@rikdriever/javascript-date-issue-since-chrome-67-50aa555799d0

which implies that Chrome (and other browsers) are going to take into account the *year* of the date when determining time zone offsets.  So, I'm going to have to figure out what to do about this, and it's probably *not* a simple fix.  We use raw date-time values (integers) with no date portion (zero for the date portion) for time values, so this is going to pose a really big problem for existing applications, especially since not all *existing* browsers behave the same way.>>>>>>>>>>

Thanks for the link Tim!! Yea, I can see the challenge.a However, I guess something eventually has to be done as probably more browser will implement the same. Did I also read that Microsoft is giving up on Edge and will start using Chromium as the main engine in Edge? Would that eventually mean that this error will start showing up in Edge as well then? I might be out of business if my users cant use Edge and Chrome

Anyhow, after reading that article I understood that this had to do with date values back on the 1900. As far as I understood, the Unix epoch started 1 Jan 1970 and thats where all datetime values will be 0. Based on that I did some "hacking" and added 2240524800000 milliseconds to all my integer time values. That means that midnight 31/121899 now became midnight 01/01/1970. That actually solved my problem with times and it now all works perfectly except the sorting. Anyhow, the sorting is not a big deal as I have already solved this by having a calculated field of type string and sort and show that in the grid instead.

So yea, this "hack" is not pretty but if that can keep my customers happy thats all that matter right now. To be clear, I only do this on time values, not datetime as I do not have any issues with them yet.

So the question is.... Is there a good place for me to intercept the generation of the JSON from the DataSetAdapter? Either on the server or on the client would do. If not I guess I can always parse the JSON after its being generate on the server and update the time values.

Eivind

Eivind,

<< Thanks for the link Tim!! Yea, I can see the challenge.a However, I guess something eventually has to be done as probably more browser will implement the same. Did I also read that Microsoft is giving up on Edge and will start using Chromium as the main engine in Edge? Would that eventually mean that this error will start showing up in Edge as well then? I might be out of business if my users cant use Edge and Chrome >>

Yes, I'm aware of the MS<->Chrome announcement.  And, again, it's not an *error*, exactly.  It's a change in how Chrome handles timezones for dates/times in the past, and it was a change in the implementation that is different from other browsers (regardless of what is happening in the future with the browser market).

I did some more looking into this issue this morning, and what I'm going to do is simply stop localizing any date or time columns, period.  Date/time (timestamp) columns will continue to be localized because they have enough information to avoid all of these problems, but anything else will always be treated as UTC.  That will eliminate these problems and allow me to finally put this issue to rest.  In hindsight, it was a mistake to even attempt to do what I was doing.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

I did some more looking into this issue this morning, and what I'm going to do is simply stop localizing any date or time columns, period.  Date/time (timestamp) columns will continue to be localized because they have enough information to avoid all of these problems, but anything else will always be treated as UTC.  That will eliminate these problems and allow me to finally put this issue to rest.  In hindsight, it was a mistake to even attempt to do what I was doing.
---------------------------------

Sorry for a delayed update regarding this matter. I'm happy to report that all my problems are gone after this update. Chrome displays time values just like any other browser now. Now I welcome Chromium engine in Edge

I will do some more testing and get back if the previously reported sorting on time columns is also fixed.