Time axis does not handle negative values - FIXED about chart-fx

[wirew0rm]

As I suppose you are not showing dates from the 1970s you are experiencing this with an uninitialized chart? This is probably why this didn't show up earlier, but of course this should be handled gracefully without throwing error messages.

If your time is not unix epoch timestamps, setTimeAxis(true) should not be called. Maybe date/epoch/timestamp Axis would be less ambigious names for this functionality. And documentation should definitely be improved. (see also: #22)

@RalphSteinhagen when looking at this, I realized that the TimeAxisSample also has some problems (in master and dev). It becomes unresponsive when zooming with the scroll wheel and zoom actions generally do not work as intended.
Edit: Did some git bisect and the commit introducing the zoom bug in the sample seems to be 9ef24ea.

[ennerf]

I figured the time axis would be generally applicable to any time data. I'm often using relative time, e.g., time from whenever the first data point starts.

Aside from the (easy-to-fix) negative number issue, starting at 0 seconds works just fine in the current implementation. Is there any reason why it needs to be limited to absolute timestamps?

Edit: I'm currently using a local fix

Edit2: For my use case it'd be enough to not crash, so just returning an empty string would work as well

if (utcValueSeconds.doubleValue() < 0) {
    return "";
}

[wirew0rm]

I guess mostly because that was the assumption when the functionality was written, so you might run into cases that are wrong or at least not well tested.

One obvious (while maybe a bit constructed) example might be, that if you plot a data interval longer than the time from EPOCH to the first leap day afterwards, you will get wrong labels from this time on.
We try to make chart-fx output as independent of localization settings as possible, but there is a Timezone setting, which also could affect your output.
These are the potential problems i can think of on the spot.

Regarding your local fix, I see the problem that if you scroll out on a month timescale, you will get negative dates, which i now saw you probably also realized, returning an empty string is also what I would have proposed.
I will get some local feedback and get it merged if there are no objections.

[ennerf]

That's a good point. It's ok to make this an unsupported feature that may run into corner cases. Most durations should be fairly short, so it's unlikely that users will hit this.

If someone uses a relative time with a time zone offset it's really their own fault :)