Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: 3.6.0
-
Fix Version/s: 3.7.0 GA (3.7.0 GA Platform Release)
-
Component/s: Server Integration
-
Labels:None
-
QA Validation Status:Validated by QA
Description
At the moment, (3.6.0 and 3.6.1) the GWT UI does not parse the parameter strings correctly. The parameter it generates use the format string "yyyy-MM-dd" and it expects all incoming and outgoing parameters to be in this format.
In the reporting engine, if Dates are passed around, we have the standard to use the ISO-date format as used in OpenOffice, OpenFormula, Excel and other tools. The ISO format is a well-defined format that allows to store and retrieve date-information in a well-defined way along with all the necessary time and timezone information. A reliable date-type representation for reports is crucial for passing data from the outside and between reports.
* The Date-Pickers valueChangeHandler always reformats the date-value entered by the user to only contain the crippled date format and thus cuts off all time values, regardless of whether the user actually requires time portions.
* The resulting URLs generated by the Date-Picker and the GWT UI generate a invalid date string that does not correspond to the standardized ISO format that the parameter handling for the reporting engine expects. Therefore it breaks the well-defined interface and generates a technical debt, as future versions are expected to accept the same crippled date strings then.
* DateTime values provided by the reporting engine (for default values given by the user or computed by a formula) are specified in the standard ISO format, which the GWT UI does not accept. As a short term fix, the GWT UI should use the 10 first characters to parse the crippled date it can handle right now.
* The text field input cannot handle user-formats and thus cannot be used to enter dates, unless we expect users to enter ISO datetime strings.
* A hidden parameter
To fix this issue:
* The Date-Picker component must be able to generate Date and time information in a reliable and well-defined way and must accept ISO date strings and must generate ISO date strings as parameter values for the reporting engine.
* The Date-Picker must have a option to either use the server-side timezone information or the client-side timezone information when time fractions are needed for the parameter type (parameter-type != java.sql.Date). I recommend to make the server-side timezone the default, as this is what will be used to query data.
Optional:
The text-fields should be able to format dates and numbers and to pass numbers in their locale independent standard format into the reporting engine.
Warning: If this issue is not addressed early on, we will generate a larger and more difficult to solve technical debt. We do need a clean and well-defined (defined outside the scope of implementation details) standard on passing *typed* parameters into the platform and the reporting engine.
In the reporting engine, if Dates are passed around, we have the standard to use the ISO-date format as used in OpenOffice, OpenFormula, Excel and other tools. The ISO format is a well-defined format that allows to store and retrieve date-information in a well-defined way along with all the necessary time and timezone information. A reliable date-type representation for reports is crucial for passing data from the outside and between reports.
* The Date-Pickers valueChangeHandler always reformats the date-value entered by the user to only contain the crippled date format and thus cuts off all time values, regardless of whether the user actually requires time portions.
* The resulting URLs generated by the Date-Picker and the GWT UI generate a invalid date string that does not correspond to the standardized ISO format that the parameter handling for the reporting engine expects. Therefore it breaks the well-defined interface and generates a technical debt, as future versions are expected to accept the same crippled date strings then.
* DateTime values provided by the reporting engine (for default values given by the user or computed by a formula) are specified in the standard ISO format, which the GWT UI does not accept. As a short term fix, the GWT UI should use the 10 first characters to parse the crippled date it can handle right now.
* The text field input cannot handle user-formats and thus cannot be used to enter dates, unless we expect users to enter ISO datetime strings.
* A hidden parameter
To fix this issue:
* The Date-Picker component must be able to generate Date and time information in a reliable and well-defined way and must accept ISO date strings and must generate ISO date strings as parameter values for the reporting engine.
* The Date-Picker must have a option to either use the server-side timezone information or the client-side timezone information when time fractions are needed for the parameter type (parameter-type != java.sql.Date). I recommend to make the server-side timezone the default, as this is what will be used to query data.
Optional:
The text-fields should be able to format dates and numbers and to pass numbers in their locale independent standard format into the reporting engine.
Warning: If this issue is not addressed early on, we will generate a larger and more difficult to solve technical debt. We do need a clean and well-defined (defined outside the scope of implementation details) standard on passing *typed* parameters into the platform and the reporting engine.
This is critical to be fixed in 3.7. At the moment (Platform 3.5-3.6.0) the time and timestamp parameter handling is basically broken as the server component does not accept timestamps as input. However, there are several good cases when doing business intelligence that you may want to look at time portions. So far we could not deliver on them while at the same time forcing our users to build creepy workarounds which later make it impossible for us to fix the issue in a clean way.
Remember: All issues that deal with system interfaces or parameter handling must be treated as blockers - at least as long as we promise that existing reports will run unchanged in future versions. Once a broken behaviour becomes standard it may be impossible to fix.