No, it doesn't. Why are you getting 32.72 in one place and 32.072 elsewhere?
Jack Mutansan wrote:. . . it still works. . . .
How strange. No, it isn't if you are going to print the milliseconds as a number on their own.
Carey Brown wrote:. . . it pads it with zeros ON THE LEFT instead of on the right.
Presumably if the last digit would have been a zero. Another twist to Winston's warning against using Strings. The toString() method can here produce a String in the wrong format.
Timestamp#toString() will sometimes return less than 3 digits. . . .
Carey Brown wrote:The documentation on Timestamp#toString() says that the default formatting is
Formats a timestamp in JDBC timestamp escape format. yyyy-mm-dd hh:mm:ss.fffffffff, where fffffffff indicates nanoseconds.
First off, this format uses 'mm' for both the month and the minutes, which is wrong.
It uses 'ss.ffff' to indicate seconds and fraction thereof, which is different than 'ss.SSS' used in SimpleDateFormat which specifies seconds and milliseconds. SDF does not support specifying 'ss.fff'.
Carey Brown wrote:I think part of your confusion is that you are not clear about when the issues is with SimpleDateFormatter#format() or SiimpleDateFormatter#parse(). If you parse with "hh" and give it '12' hours it will create the correct number of milliseconds. However, when you use "hh" to reformat it you will get '00' for the hours.
In my last post I found that HH vs hh DOES make a difference. You were correct. It chokes if you give it '12' hours. Best not to assume that the creator of SimpleDateFormat can cover all the cases where you use HH or hh incorrectly.
Jack Mutansan wrote:Got it. I should use HH to format it if I want to see it in 0-24 form, given it is a timestamp. But for parsing the timestamp string using hh or HH doesn't make difference.