From: Alan S L. <al...@us...> - 2004-03-11 20:20:45
|
Further clarification: Trailing zeros and rounding behave as follows: Given the time 1:30:01.5, the following behavior is seen: ss.S => 01.5 ss.SS => 01.50 ss.SSS => 01.500 Formatted output strings are rounded. Given the time 1:30:01.567, the following behavior is seen: ss.S => 01.6 ss.SS => 01.57 ss.SSS => 01.567 Given the pattern "h:mm:ss.SS", the following behavior is seen: "1:30:01.5" => 1:30:01.500 "1:30:01.56" => 1:30:01.560 "1:30:01.567" => 1:30:01.567 "1:30:01.5678" => 1:30:01.568 Note that in the last line, rounding applies to *parsing* as well as formatting. [Alan S Liu/San Jose/IBM@IBMUS; al...@us...;; IBM Globalization; 5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155] __________________ On further thought, I think the 'S' field should implement half-up rounding. [Alan S Liu/San Jose/IBM@IBMUS; al...@us...;; IBM Globalization; 5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155] __________________ Proposal: Change semantics of 'S' from "milliseconds" to "fractions of a second." This will make the 'S' field more generally useful in patterns such as "hh:mm:ss.S" immediately, and will allow for any future changes in which time representation is changed from having millisecond resolution. Currently the 'S' field in DateFormat is defined to display milliseconds. I would like to change this definition so that it displays fractions of a second. That is, given the time 1:30:01.234567891, or 234,567,981 ns after 1:30:01, the following format behavior is proposed: ss.S => 01.2 ss.SS => 01.23 ss.SSS => 01.234 ss.SSSS => 01.2345 etc. The current proposal is to *truncate* the result with no rounding. This conforms to the general policy in DateFormat in which fields are not rounded, but truncated. E.g., hh:mm does not display "1:31" if the time is 1:30:59. However, the case of fractions of a second is perhaps different, since it is a non-integral field. An alternate proposal is to implement simple HALF_UP rounding. This will occur up to the limit of 1 nanosecond, that is, the maximum supported width is 9 characters: SSSSSSSSS. Note: This behavior is *partially* implemented in ICU4C already, and not implemented at all in ICU4J. Please reply with comments to this list. [Alan S Liu/San Jose/IBM@IBMUS; al...@us...;; IBM Globalization; 5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155] _______________________________________________ icu mailing list ic...@os... http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu |