more on Horizontal Date Axis

[Charles H Martin]

In a recent topic thread on the Horizontal Date Axis, it was stated that:


"By default, the range showing on your date axis is driven by the data, not by settings on the axis. The x-values from your dataset are interpreted by the date axis as "milliseconds since 1-Jan-1970" (the encoding used by java.util.Date). So you need to look at how you created your dataset..."


Consider the Demo with the 4 vertically combined data sets. Here,
the x-values are dates, and there is no data for the weekends.
Because the Date Axis converts Date -> millisecond, it leaves
holes in the data on the weekend. This is a problem for many
stock market/ financial applications, since this skews the graph
and can screw up the interpretation of graphs certina technical
charts like the fast Stochastic.

Does anyone have a quick fix for this>

I would think that another kind of DateAxis, could be created, which converts date to x-value using something like ( tick# )/ (#ticks).
So for a dataset with 100 days,tick 3 -> 0.03, tick 15 -> 0.15, and so on

Is there something easier than this?

Thanks
Charles H. Martin

[Morpheus]

If I'm not wrong, You mean that u should start drawing from monday to friday and then step the weekend and start again from monday. Maybe u should have a look to Calendar.DAY_OF_WEEK, and consider extending class DateTickUnit by adding field DAY_OF_WEEK, and then consider extending HorizontalDateAxis ( VerticalDateAxis ) by overriding method previousStandardDate...

Looking forward for ur comments

Regards
Morpheus

[Charles H Martin]

This is almost correct and an excellent idea...

Notice, however, that the datasets will also, every once in a while, have missing days in the week due to holidays.
(These days can be specified using the Business Calendar classes that are part of JFinance)

Also, it may be desirable to display the dates using a day, hourly, or minute tick even if the data only contains prices for business trading days .
(Indeed, the zoom feature really should try to figure this out automatically)Will this require displaying the data only in one specific tick format?


So I think that this is part of the solution, if I understand what previousStandardDate is used for (see below)

If this is used, whcih I will experiment with, then it may serve to "fool the boss", but I think it will still introduce a bit a of a skew in the graphs on certain Holdays (and the dates around 11, September, 2001 will be very skewed since a whole week of trading data is missing)


I think I have another part of a complete solution, which is to create and use aTradingDate class that decorates the java.util.Date class and has some additional method like getTradingTime() that returns the time in milliseconds from Jan 30, 1970, not including weekends and/or holidays: getTradingTime() = getTime() - (#nonTradingDays)*(#millis/day)

The problem here is also with how previousStandardDate and some other classes and methods (such as DateRange, DateAxis, DateTickUnit, etc)


Most of these would look the same, except where new Date() is used,
one would need new TradingDate(); calls to getTime() might be replaced with getTradingTime(); one would need an some fix to when the java Calendar is used (such as in previousStandardDate); ,and changes must be made whereever else assumptions are made regarding the structure of the calendar/dates (such as in DateTickUnit.getMillisecondCount() to assume each month has 20-21 days)

Could you (or someone else) explain to me what previousStandardDate does and how it is used? Does it return the closest Date <= the Date at the current tick?

Is it only used to compute the minimum and maximum values in the DateAxis?


Also,

[David Gilbert]

> Could you (or someone else) explain to me what previousStandardDate
> does and how it is used? Does it return the closest Date <= the Date at
> the current tick?

Suppose you have requested tick labels at 10 minute intervals, and you have a java.util.Date equal to 23-Feb-2003, 15:33:51. The previousStandardDate(...) method should return 23-Feb-2003, 15:30:00, because that is the closest prior date that is "rounded off" to the tick unit interval.

Regards,

Dave Gilbert

[Charles H Martin]

Thanks, this is what I thought