JfreeChart I18N and Dates

[Colin Evans]

Hi David!

First, JFreeChart is a great piece of software! Congratulations and thanks for all of the hard work.

I'm running into internationalization problems with time series charts. The charts are being generated for the default Timezone that the JVM is running in, and it would be nice if this could be configurable so that I could render charts that are local to the viewer's timezone. It seems like BasicTimeSeries or TimeSeriesCollection should have some sort of setLocale() or setTimeZone() method on it so that I could set the time zone that the dates are for.

Am I missing an existing way of configuring this?

Thanks!

Colin Evans

[Reji Mani]

Hi,

While creating BasicTimeSeries use MilliSecond.class. That will solve Timezone problem. but Hour,Minute and Second classes are having TimeZone bugs..

Regards,

[jim]

I'm a total nube, but I did notice that DateAxis has a getTickLabelFormatter that returns a SimpleDateFormatter, which inherits a setCalendar and setTimeZone from DateFormat, so you can try your luck there. I'll be running into the sam problem shortly so I hope this works.

Jim

[David Gilbert]

The timezone problem for all the subclasses of TimePeriod (except Millisecond) in the JCommon class library is due to the conversion to milliseconds in the getStart() and getEnd() methods of the Day class. Modify those methods to take into account the timezone and all the other classes should fall into line. I need to do some reading about the TimeZone class before I do this myself...if anyone else has some code that works, please post it here, lots of people will be very grateful.

Regards,

Dave Gilbert

[jim]

I believe the millisecond value in java represents the number of millis since Jan 1, 1970 UTC, so the value is not timezone sensitive. The timezone value only becomes significant when you do calendar arithmetic or format the date as a string. Math with milliseconds doesn't need to be tz sensitive, but the TimePeriod class might need a calendar object inside of it to compute the proper values of next () and previous (). I *really* need this feature to work, so I am going to do some experimenting soon and will post my results.

Jim

[David Gilbert]

Hi Jim,

You and I can agree that 15-Feb-2002 (for example) represents one particular day, even if your 15-Feb-2002 is slightly offset from my 15-Feb-2002 in time because we live in different places (timezones). I use the Day class (and the other TimePeriod subclasses) to represent this slightly inconsistent but very common view of the world (that is, where one day is the same as another even if they are in different time zones).

I like java.util.Date (and the associated Calendar classes) because it is a very logical and consistent model. But sometimes people just want to compare (for example) the closing stock index value in London on 15-Feb-2002 with the closing stock index value in New York on the same day...5 hours difference, but few people care. So in those cases I use my Day class.

Now, I think the problem arises because I have provided two methods getStart() and getEnd() that are supposed to return the milliseconds (equivalent to a java.util.Date) representing the first and last millisecond of the given TimePeriod...but your view of what is the correct answer in that case is going to depend on your time zone. At the moment, the methods return the millisecond assuming GMT.

I think there are two solutions to this problem:

(1) Adjust the getStart() and getEnd() methods in the Day class to take account of the timezone. This should filter through the other TimePeriod subclasses, since most of them use the Day class internally.

(2) Add new axis classes to JFreeChart that can handle TimePeriod classes directly, rather than converting to java.util.Date, allowing the timezone to be ignored as intended. This would involve creating a new dataset that returns (TimePeriod, Number) data items, plus plots that can support this type of data.

Solution (1) will be the easiest to implement, solution (2) perhaps easier to work with after it is implemented. Both solutions could co-exist quite happily, so eventually I'd like to see them both done.

DG.

[jim]

Hi David,
First, let me give you and your colleagues props for JFreeChart. I have been long suffering with another charting package and yours seems to completely blow it away. (I say seems only because I don't have anything implemented in JFreeChart yet )

What I meant in my previous post is that the java.util.Date class represents the number of milliseconds since Jan 1, 1970 00:00:00.000 UTC, so it is not timezone sensitive. java.util.Calendar wraps Date to provide for locale sensitive arithmetic. Day Light Savings time in certain timezones makes a real mess out of the idea of a TimePeriod because a day can have 23, 24, or 25 hours depending on what day of the year it is, which of course has a cascading impact on all the containing TimePeriod classes (week, month). And let's not forget about leap years (and seconds). Sorry for the primer, but this was the bane of my existence last year when I was implementing an analysis engine in c last year. (The c time libraries are god awful hoary). Also, for some of our customers, a day goes from 9AM to 9AM, sometimes a month is always 30 days, a month begins on the 15th, etc. The blessed java.util.Calendar makes it easy to deal with all of these rules, so from what I see passing one to a TimePeriod object will provide some flexibility in this regard. I looked through a small portion of your excellent code, and saw a couple of calls to Calendar.getInstance (), which will probably need to be replaced by a user provided calendar for full i18n effect, along with setting the proper calendar in the DateFormatter. Again, my apologies if this is obvious.

Jim

[GreGie]

Hi all,

I think I have a workaround for some of the problems encountered in TimeSeries. While you do the parsing, you might want to fix the time zone to "do nothing" using this line:

java.util.TimeZone.setDefault(java.util.TimeZone.getTimeZone("UTC"));

IMHO, I should be able to just parse things in and get them out again from any TimePeriod without change, or with only the change I explicitely want to. This is not possible with the current implementation of TimePeriod and the derived classes.

At the moment, this code fails depending on the TimeZone:
public void testFormatMin() {
Minute min1= new Minute(40, new Day(28, 2, 2002));
String stringRet = formatMin(min1);
assertEquals("Minute formatting fails",
"20020228 00:40", stringRet);
}

private static SimpleDateFormat minFormatter =
new SimpleDateFormat("yyyyMMdd HH:mm");
public static String formatMin(Minute min) {
dummyDate.setTime(min.getMiddle());
return minFormatter.format(dummyDate);
}

It took me a long time to figure out what exactly the Date and Calendar classes are doing (Date encodes a time with millisecond precision location independent, and Calendar will give you a representation in whatever time zone/calendar system you want), but once this is clear (it also took Java a version step until they realised it), there is some inherent beauty to it.

I have an idea for an implementation of TimePeriod using Date (or the corresponding long) internally, and a static long TIME_PERIOD_LENGTH. The Date would be TimePeriod.getMiddle(), and the getStart() and getEnd() would be derived from that. All you then need is a reasonable constructor from Date, and the previous() and next() functions are taken care of automagically!

David, I don't know what that would do to your SerialDate class, but I perceive the SerialDate class to be a hack around the Date problems you describe in the JavaDoc. Maybe this approach is better suited to the smaller TimePeriod units?

Jim, I'm not quite sure how to implement the desired Calendar features of the previous posts, but it might be possible to even have them in the TimePeriod class. Maybe that should be taken care of by a Parser and Formatter, which can be set (statically?), using a given TimeZone.

I think that from a design point of view, the Minute object should represent the exact same minute anywhere on the planet (or off-planet, if you trust this code enough , and localisation should be done when parsing or formatting the input/output.

What I'm sure of is that I won't have time until close to May to implement a grand unified scheme. There is some old code to look at for someone interested in working along these lines.
All I can do for the moment is point out a bug in the Minute(Date) constructor. The JUnit code is:

Minute min = new Minute();
Minute min2 = new Minute(new Date(min.getMiddle()));
assertEquals("Minute getMinute?", min.getMinute(), min2.getMinute());

This code will fail under any circumstances, but even with the proper implementation of Minute it will fail if you're not in UTC.

I believe it is this line in the Minute(Date date) constructor:
this.minute = (hour*60)+min+1;

Uff, this got longer than I thought. Hemingway, I hope at least the quickfix given above works for some people.

Greetings,
GreGie

[Jim McLaughlin]

Hi GreGie, et al

First, let me admit to being a total nube with a less than comprehensive grasp of the code base.

What I was trying to point out above is that you can't count on a Day having 1440 Minutes or 24 Hours, etc, because of locale specific rules. Some of the TimePeriod classes have assumed this, however. Unfortunately, I wasn't able to use any of the TimePeriod classes because our customers have their own ideas of what a TimePeriod is (a Day from 9AM to 9AM, a month from the 15th to the 15th) so I'm not really sure what is right or what is wrong with the design. I subclassed my own FlexibleTimePeriod that is locale sensitive and flexible enough to meet the demands listed above. It is pretty much like the DateUnit class. I've attached it below in hope that it might help.

public class FlexibleTimePeriod extends TimePeriod {

private final Calendar end;
private final int calendarField;
private final int numCalendarFields;

public FlexibleTimePeriod (Calendar end, int calendarField,
int numCalendarFields) {
this.end = (Calendar) end.clone ();
this.calendarField = calendarField;
this.numCalendarFields = numCalendarFields;
}

public long getEnd () { return end.getTime ().getTime (); }

public long getMiddle () {
final Calendar tmp = (Calendar) end.clone ();
tmp.add (calendarField, (-1*numCalendarFields));
final long endMillis = end.getTime ().getTime ();
final long startMillis = tmp.getTime ().getTime ();
return ((endMillis + startMillis)/2);
}

public long getStart () {
final Calendar tmp = (Calendar) end.clone ();
tmp.add (calendarField, (-1 * numCalendarFields));
return tmp.getTime ().getTime ();
}

public TimePeriod next () {
final Calendar tmp = (Calendar) end.clone ();
tmp.add (calendarField, numCalendarFields);
return new FlexibleTimePeriod (tmp, calendarField, numCalendarFields);
}

public TimePeriod previous () {
final Calendar tmp = (Calendar) end.clone ();
tmp.add (calendarField, (-1*numCalendarFields));
return new FlexibleTimePeriod (tmp, calendarField, numCalendarFields);
}

public int compareTo (Object o) {
final FlexibleTimePeriod rhs = (FlexibleTimePeriod) o;
final Calendar rhsCal = rhs.end;
if (end.equals (rhsCal)) return 0;
else if (end.before (rhsCal)) return -1;
else return 1;
}
}

[GreGie]

Jim,

this looks like TimePeriod should have been! I haven't tried it yet, but have a couple of questions:

Is there a special reason for all the final statements?

And maybe I'm thick, but wouldn't
getMiddle() {
return (getEnd() + getStart()) /2);
}
do the trick?

I see that your and my problems are quite different... which shouldn't keep your solution to work for me!
I'm not sure though whether this is what I had in mind...

How do you parse something in and get it out again?

Could you also post a few lines how you use this? Eg, build a Minute equivalent? Trust me on that, I haven't got much of an idea of the code base myself...

Cheers, GreGie

[Jim McLaughlin]

Hi GreGie,

>> And maybe I'm thick, but wouldn't
>> getMiddle() {
>> return (getEnd() + getStart()) /2);
>> }
>> do the trick?

I get paid by the line

Yes, you're quite right. In fact there is a couple of things I would change looking at it now. Originally I was using the Calendar to pass in the Date object for the TimePeriod. Since I wasn't really sure if a Calendar munges the internal Date when you call add or roll, I did the cloning in the various methods. It turns out the Calendar does not modify the Date passed to setTime (), so the clones do nothing but exercise the gc. If I were to do it again now, I would pass the Date and a Calendar to the ctor and get rid of the cloning (with its uncertain combo of value and reference semantics, I never know if the java class libraries are doing a deep copy or a shallow one. In this case, it turns out to be a non-copy, but they don't really mention it in the docs). I also think FlexibleTimePeriod is a bad name because you can't use it to mix TimePeriods.

I'm not sure what you mean by parse something in and get it out. Do you need some other functionality that isn't provided by java.text.SimpleDateFormat.parse (String dateStr)? I haven't needed anything else, so I haven't thought about it. However, from a design standpoint, I don't think I would put such functionality in the TimePeriod.

Building a Minute (assuming changes mentioned above):
FlexibleTimePeriod oneminute = new FlexibleTimePeriod (calendar, date, Calendar.MINUTE, 1);
FlexibleTimePeriod fiveminute = new FlexibleTimePeriod (calendar, date, Calendar.MINUTE, 5);

As for the 'final' qualifiers, I was brainwashed by my compilers prof into thinking they were indispensible for catching a whole class of programmer errors and assisting the compiler with optimization. I have no scientific proof, but the man was a god...

[GreGie]

Jim,

after all I've seen, you're right: once a Date is a Date, it doesn't change any more.

The parsing meant that SimpleDateFormat parses the string taking the local time zone into account. This can go wrong if you have data already set to UTC or another local time zone. Often, it also introduces a jump right at the summertime/wintertime switch, which can throw calculations off that are based on continuous time.

Do I make sense here? I'm using this for meteorological data, which comes with a time stamp in UTC (usually), and if I parse this without worrying about the time zone, it will introduce problems I wouldn't have otherwise.

Laters, GreGie

[Jim McLaughlin]

Hi GreGie,

You need to set up the proper TimeZone and Locale for your DateFormatter. Take a look at java.util.Calendar, java.util.TimeZone, and java.text.DateFormat. Here is a very basic example to make sure DateFormat knows the string to be parsed is in GMT (UTC):

final TimeZone tz = TimeZone.getTimeZone ("GMT");
final Calendar cal = new GregorianCalendar (tz);
final DateFormat df = new SimpleDateFormat ("yyyy-MMM-dd HH:mm");
df.setCalendar (cal);
final Date date = df.parse ("2002-Mar-26 11:49");

hth,

Jim