Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RangeBar Displays Wrong Time Values on X-Axis #1607

Closed
Gari-sincere opened this issue May 14, 2020 · 11 comments
Closed

RangeBar Displays Wrong Time Values on X-Axis #1607

Gari-sincere opened this issue May 14, 2020 · 11 comments
Labels
bug Something isn't working high-priority timeline

Comments

@Gari-sincere
Copy link

Gari-sincere commented May 14, 2020

Thanks for your work on this library :) Keep up the good work!

Bug report

RangeBar Displays Wrong Time Values on X-Axis

Codepen

https://codepen.io/GariSincere/pen/ZEbMKPJ

Explanation

What is the behavior you expect?
The x-axis should line up with the tooltip and the JSON of the datapoints

What is happening instead?
The x-axis is intermittently off by 1 hour and disagrees with the tooltip (which is lining up with actual data points)

image

The issue seems to be related to the plot range. As you can see from the code pen, after one of the series is hidden the plot range changes, and the axis labels are then correct. Sometimes adding data points that extend the plot range will also set it back on track.

It might be related to #1601 and is distinct from #1485 since it is not reflective of timezones and is consistently off in safari vs non-safari.

Currently, I can't find any way to work around this issue :/ If manual tick options were added as suggested in #1590 I could work around this issue until it is solved.

@junedchhipa junedchhipa added bug Something isn't working timeline labels May 15, 2020
@aswincoolsaet
Copy link

working with UTC will solve it !

data :
[
{ x: 'Ma', y: [ Date.UTC(2019, 2, 7, 10, 20, 0) , Date.UTC(2019,2,7, 22, 0, 0) ] },

...

formatter: function (x)
{
let oDate = new Date(x);
console.log(x);
return '' + zeroPad( oDate.getUTCHours() , 2 ) + ':' + zeroPad( oDate.getMinutes(), 2 );

                                                             }

@Gari-sincere
Copy link
Author

@junedchhipa for him to see the progress.

Yes, thank you @aswincoolsaet that is progress! I updated the code pen to have a third chart that uses the UTC formatter. Now at least the axis is agreeing with the data, but a new issue is now the axis ticks are irregular and displaying poorly (the last one is cut off). I guess that is a side product of using manual formatter? I have tried to tweak the formatter settings but can't seem to improve it.

@aswincoolsaet
Copy link

ah I understand.
I don't have much time this evening to try out, but try here something with UTC option to turn it off
https://apexcharts.com/docs/options/xaxis/

@aswincoolsaet
Copy link

Can you try to use Date.UTC(2019, 2, 7, 10, 20, 0)

instead of new Date( ... ) ?

@Gari-sincere
Copy link
Author

Yes, I used that function at first but found that the outcomes were equivalent in the example case I currently have in the code pen.

@aswincoolsaet
Copy link

y: [
        Date.UTC(2020,4,14,1), //  ("Thursday, May 14, 2020 1:00:00 AM GMT").getTime()
         Date.UTC(2020,4,14,3) //new Date("Thursday, May 14, 2020 3:00:00 AM GMT").getTime() 
      ]

&&&

xaxis: {
labels: {
datetimeUTC: false,
},
type: 'datetime'

does it for me in your codepen.

@Gari-sincere
Copy link
Author

Gari-sincere commented Nov 9, 2020

YES is see what you mean. It looks like using Date.UTC() create function and xaxis.labels.datetimeUTC : false is the secret sauce. The formatter function is not necessary and was causing those display issues.

image

I'm still curious on what was going wrong :/ I bet it has something to do with daylight savings time conversions (since the difference was typically 1 hour).

Regardless it's GREAT to have this workaround in the meantime.

@aswincoolsaet
Copy link

ok I had more time to test now.
for instance : 9:30 - 10:00

datetimeUTC: false, will fix the wrong offset with new Date( .. )
and the label can be fixed by the formatter function where you can use getUTCHours

so the only issue I still have is a little bit wrong "offset" on the x-as.

image

@magynhard
Copy link

I have the same issue. It seems that it has to do with the day change in combination of non-UTC.

The missing piece is the x-axis label for the new day, which might not consider timezones correctly - it is missing and so the x-axis is delayed by one element from that.

Here I'm at UTC+2:00 (at summer time, Europe/Berlin). The problem occurs only when i select a start date between 22:01 and 22:59, then the x-axis item for day is missing. When starting <= 22:00 or >= 23:00 it is working fine.

@Kkura02
Copy link

Kkura02 commented Nov 14, 2022

I have similar problem too, but mine is it display incorrect hour, but display the correct minutes. How should I fix this?
image

as you can see in the image above, the time format is 'hh:mm' but the hour is incorrect compared to my current time.
image

the tooltip seems to be functioning well thou, as it shows this:
image

I tried doing this code:
code

and it now shows the correct hour, but my intervals are now messed up and also each label updates too, which i do not want with my x axis.
image

can someone help me, on what I must do to fix this problem. Thank you.

Update: I already solved this and I identified the reason why it displays the incorrect hours. It was because of a different time format being used; In summary it was using datetimeUTC. and the solution i made is to declare the use of it as false... see this image below for reference...
image

@junedchhipa
Copy link
Contributor

The original issue is fixed as tested on v4.3.0
Screenshot 2024-12-25 at 11 12 19 PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working high-priority timeline
Projects
None yet
Development

No branches or pull requests

5 participants