Options
"Not a Bug With Date_time"
Maven
Hey,
I found out that Rapid Miner has a weird quirk.
It puts a 00, where it should put a 12.
Using the nominal to date operator, with yyyy-MM-dd hh:mm:ss as time format.
To fix this you have to use yyyy-MM-dd kk:mm:ss
http://www.few.vu.nl/~wln320/machine/rapid%20miner%20bug.gif
Best regards,
Wessel
I found out that Rapid Miner has a weird quirk.
It puts a 00, where it should put a 12.
Using the nominal to date operator, with yyyy-MM-dd hh:mm:ss as time format.
To fix this you have to use yyyy-MM-dd kk:mm:ss
http://www.few.vu.nl/~wln320/machine/rapid%20miner%20bug.gif
Best regards,
Wessel
Tagged:
0
Answers
this is actually the desired behaviour and not a bug as far as I can see. From the operator's manual:
- H: hour in day (0-23); Number; example: 0
- k: hour in day (1-24); Number; example: 24
- K: hour in am / pm (0-11); Number; example: 0
- h: hour in am / pm (1-12); Number; example: 12
As you can see, the "h" as it was used in your first try is used for parsing numbers between 1-12 where 12 am corresponds to 00 in 24-hour format. If your data actually contains 24 hour dates you will have to use either "H" or "k" depending on the first counted number as stated above.This is actually directly taken from Java date parsing. More information can be found at
http://download.oracle.com/javase/1.5.0/docs/api/java/text/SimpleDateFormat.html
Hope that helps,
Ingo
You are right it is not a bug.
I called it a weird quirk because I did not understand it and it was given me a lot of trouble.
Now that I do understand it, it all makes sense, and this post isn't really necessary.
But the understanding came after that I posted it
Best regards,
Wessel
I only just realized that the topic subject started with "Not a bug..." - sorry for the confusion. However, maybe this thread can help others if they stumble upon the same phenomenon.
Cheers,
Ingo