| Grouping data for table by date gives wrong results [message #250159] |
Fri, 27 July 2007 09:32  |
Eclipse User |
|
|
|
We are generating a table that lists the number of records by day. The
table
appears as follows. Note the duplicate dates.
Date Count
Jul 6 1
Jul 19 129
Jul 19 319
Jul 21 9
Jul 21 32
Jul 23 166
Jul 23 276
Jul 24 11
The correct data should be
Date Count
Jul 6 1
Jul 19 142
Jul 20 306
Jul 21 27
Jul 22 14
Jul 23 170
Jul 24 274
Jul 25 9
The problem is in the group calculation. We are grouping off a LOCAL
date/time, using an Interval of Day and range of 1. When the groups are
calculated, BIRT is apparently converting the date/time provided to UTC
time based on the systems timezone, extracting the date and using that to
determine what "bucket" to put the record in. However, when displaying the
days in the first column, BIRT is taking the timestamp from the first
record
in the bucket as a LOCAL date/time and extracting the date. This causes
the repetition in the dates displayed in the first column, and the
incorrect counts in the second column.
The timestamps should always be treated as local date/time, and not
adjusted to UTC time. This would give us the correct data.
By the way, we are also generating a column chart showing the same data,
using the same input, and it groups the data by date correctly and shows
the correct number for each column.
Is there any way to make the table group interpret the date/time as a
Local timestamp instead of converting it to UTC?
Earl Bennett
|
|
|
| Re: Grouping data for table by date gives wrong results [message #250204 is a reply to message #250159] |
Fri, 27 July 2007 13:45  |
| Eclipse User |
|
|
|
I've solved part of the problem. We had the data to be displayed in the
table defined in the group header row. When I moved it to the group footer
row, the date displayed for each row is from the last record in each
bucket. In this particular case, that turns out to be correct.
However, the counts are still off. Records that should be grouped into
one bucket are being placed in the next one because of the timestamp being
shifted to UTC time.
Earl
|
|
|
Powered by
FUDForum. Page generated in 0.05874 seconds
Home