Re: Proposal: Clarification of DateFormat 'S' field

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; [email protected];; 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; [email protected];; 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; [email protected];; IBM Globalization;
5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155]
_______________________________________________
icu mailing list
[email protected]
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu