Just saw few tests are failed, I haven't had time to look closely, since I haven't figured out how to run a single test instead of the whole suite, but I think it means few tests need to be changed and not due to an issue in the code.

Thanks for the PR@mshvarts - can you please update the tests as well? Once that's done I'll see if I can find a reviewer. Thanks -@gvwilson

Thanks for the PR@mshvarts - can you please update the tests as well? Once that's done I'll see if I can find a reviewer. Thanks -@gvwilson

Sorry I work full time and don't have time now. I can try to look into it later if you let me know how to run individual tests on my machine? Every time I tried adding flags it just ran the whole test suite instead and takes forever to complete.

Thanks for the PR@mshvarts - can you please update the tests as well? Once that's done I'll see if I can find a reviewer. Thanks -@gvwilson

Sorry I work full time and don't have time now. I can try to look into it later if you let me know how to run individual tests on my machine? Every time I tried adding flags it just ran the whole test suite instead and takes forever to complete.

Hi@mshvarts, thank you for the PR!

You can run a single test filename by passing the filename, e.g.npm run test-jasmine bar_test.js. That's probably the best way to try to reproduce these failures on your local machine, since as you mentioned the full test suite takes a long time to run.

Within a file, you can also run just a single test by changingit( tofit(, ordescribe( tofdescribe( (Jasmine docs ref).

I'll try to find some time in the next few days to look at the test failures; we have a few tests which are sometimes flaky so the failures may or may not be due to these changes.

I looked into the test failure briefly (as I need this functionality), and removing all changes except the one on line 29 makes it pass the hover_label test, but still renders error bars for me (I have not run all the other tests).

For'date' axes, theax.c2l andax.l2c conversions callLib.ensureNumber, but when the axis type is'log' the conversions instead convert to and from log, which seemingly causes the hover_label test failure. Perhaps callingLib.ensureNumber directly is better (if it is needed at all)?

@mshvarts Yes,@oskarr is correct, I did some testing of my own and the change on line 29 is the only change technically needed to enable these error bars. The other changes adding theax.c2l andax.l2c conversions actively causeincorrect results for log axes (because it causes the error values to be calculated on log values rather than on raw values). And they have no effect on date axes anyway.

So reverting all the changes except for the line 29 change is a good start.

However the resulting outcomeonly works when the error bar size is specified in milliseconds, and it's possible we should support string values as well, so more work will be needed.

it's possible we should support string values as well

I'd suggest not blocking on that. As long as we want to support milliseconds as a format - which I think is the right call, and the only plausible interpretation of numbers here - then we can add string handling as a separate effort. Or more generally, other ways to provide this data; strings are good if we can settle on a clear and flexible standard for specifying time intervals, but another option would be to split it into two attributes: units (that default to milliseconds but could be any other time unit) and a number.

@alexcjohnson Fair enough! If you're fine with that limitation it's fine with me as well.

@mshvarts Here's a mock showing the 4 different types of error bar specifications in combination with a date axis.

JSON:

{"data": [    {"name":"percent","x": ["2025-11-05","2025-11-06","2025-11-07"],"y": [10,12,11],"error_x": {"type":"percent","value":0.001      },"type":"scatter"    },    {"name":"constant","x": ["2025-11-05","2025-11-06","2025-11-07"],"y": [7,9,8],"error_x": {"type":"constant","value":10800000      },"type":"scatter"    },    {"name":"sqrt","x": ["2025-11-05","2025-11-06","2025-11-07"],"y": [4,6,5],"error_x": {"type":"sqrt"      },"type":"scatter"    },    {"name":"data","x": ["2025-11-05","2025-11-06","2025-11-07"],"y": [1,3,2],"error_x": {"type":"data","array": [7200000,14400000,21600000]      },"type":"scatter"    }  ],"layout": {"title": {"text":"Error bars along date axis"    }  }}

Plot image:

@alexcjohnson It seems to me that both thesqrt type andpercent type are not relevant for dates since the zero point is arbitrary, do you agree? And in that case should we explicitly disallow those types for dates, or allow them to exist even though they are not meaningful?

Yeah that's right,sqrt andpercent make no sense for dates. Unix may have decided that 1970 is the origin but that doesn't mean much to the rest of the world 😉 But do we even have access to the axis type duringsupplyDefaults? I thought it was calculated later. If not, we can document that these will be ignored for date axes.