Thanks, but there seems to be a bug or error in the documentation:
In your example, you used "Z". According to the example in the documentation, +00:00 should be accepted as-is:
Z: This pattern letter represents the time zone. This pattern letter follows the rules of the 'RFC 822 Time Zone' format type. Examples include -08:00 etc
However, -08:00 is not valid in RFC822, only -0800 would be valid.
Would it be possible to create a bug/feature request? Suggested fixes and enhancements:
* Fix the example in the documentation to replace +08:00 by +0800 so that it is valid according to RFC822
* Allow fractional seconds (sub-milliseconds) using .SSSSSSSSSSS (S repeated depending on number of digits)
* Introduce a new custom format for time zones written as +00:00 (non-RFC 822)
while the problem with the time zone offset one can circumvent by using a regular expression to make the string match the standard, I would definitively support the sub milisecond resolution. In technical applications like predictive maintenance, etc, we often have nano second precision in the time stamps and multiple events per mili second. This is currently not handable by RapidMiner.
Unfortunately this probably requires some more drastic changes as nano seconds cannot be saved as double anymore, due to limited integer range: We would always loose precision by internal rounding. All operators would need to learn how to handle that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.