We're updating the issue view to help you get more done. 

Consistent pivot behavior for years

Description

Deleted Component: formatting

This goes back to our discussion of yy, and how to combine this with pivots for
yyyy (as Windows does). Let's discuss in the staff meeting; will be easier than
email.

Mark

Alan Liu
2003.05.23 10:19


Maybe we can talk about this more at the next staff mtg. I think I'm missing
part of the discussion –

You state:
would allow single digit output, which we should have for Japanese
would ensure that all years can be parsed (right now, 8 AD can't be parsed
correctly)

We can do single digit output, and we can parse all years (incl. 8 AD), using y
format. I must be misunderstanding.

I ran a quick experiment. The lines marked Err have a round-trip mismatches,
but these are all as-designed.

MM/dd/y
parse(12/25/8) => Y 8
parse(12/25/1008) => Y 1008
parse(12/25/1952) => Y 1952
parse(12/25/2008) => Y 2008
Err parse(12/25/08) => Y 8 as expected; 08 only maps
to 2008 with yy
format(Y 8) => 12/25/8 => parse => Y 8
format(Y 1008) => 12/25/1008 => parse => Y 1008
format(Y 1952) => 12/25/1952 => parse => Y 1952
format(Y 2008) => 12/25/2008 => parse => Y 2008
format(Y 2008) => 12/25/2008 => parse => Y 2008
====================
MM/dd/yy
parse(12/25/8) => Y 8
parse(12/25/1008) => Y 1008
parse(12/25/1952) => Y 1952
parse(12/25/2008) => Y 2008
parse(12/25/08) => Y 2008
Err format(Y 8) => 12/25/08 => parse => Y 2008 as expected; 08 maps to
2008 with yy
Err format(Y 1008) => 12/25/08 => parse => Y 2008 as expected; 08 maps to
2008 with yy
format(Y 1952) => 12/25/52 => parse => Y 1952
format(Y 2008) => 12/25/08 => parse => Y 2008
format(Y 2008) => 12/25/08 => parse => Y 2008
====================
MM/dd/yyy
parse(12/25/8) => Y 8
parse(12/25/1008) => Y 1008
parse(12/25/1952) => Y 1952
parse(12/25/2008) => Y 2008
Err parse(12/25/08) => Y 8 as expected; 08 only maps
to 2008 with yy
format(Y 8) => 12/25/008 => parse => Y 8
format(Y 1008) => 12/25/1008 => parse => Y 1008
format(Y 1952) => 12/25/1952 => parse => Y 1952
format(Y 2008) => 12/25/2008 => parse => Y 2008
format(Y 2008) => 12/25/2008 => parse => Y 2008
====================
MM/dd/yyyy
parse(12/25/8) => Y 8
parse(12/25/1008) => Y 1008
parse(12/25/1952) => Y 1952
parse(12/25/2008) => Y 2008
Err parse(12/25/08) => Y 8 as expected; 08 only maps
to 2008 with yy
format(Y 8) => 12/25/0008 => parse => Y 8
format(Y 1008) => 12/25/1008 => parse => Y 1008
format(Y 1952) => 12/25/1952 => parse => Y 1952
format(Y 2008) => 12/25/2008 => parse => Y 2008
format(Y 2008) => 12/25/2008 => parse => Y 2008

When I hack in the yyy handling that we discussed (but which isn't in 2.6):

MM/dd/yyy
parse(12/25/8) => Y 8
parse(12/25/1008) => Y 1008
parse(12/25/1952) => Y 1952
parse(12/25/2008) => Y 2008
parse(12/25/08) => Y 2008
format(Y 8) => 12/25/008 => parse => Y 8
format(Y 1008) => 12/25/1008 => parse => Y 1008
format(Y 1952) => 12/25/1952 => parse => Y 1952
format(Y 2008) => 12/25/2008 => parse => Y 2008
format(Y 2008) => 12/25/2008 => parse => Y 2008

This is nice because "08" is parsed as 2008, but formats as "2008".

Alan Liu
IBM GCoC - San Jose

Mark Davis
05/22/2003 06:07 PM
To: Steven R Loomis/Cupertino/IBM
cc: Alan Liu/Cupertino/IBM@IBMUS, Andy Heninger/San Jose/IBM@IBMUS, Doug
Felt/Cupertino/IBM@IBMUS, Eric Mader/San Jose/IBM@IBMUS, George Rhoten/San
Jose/IBM@IBMUS, Helena S Chapman/San Jose/IBM@IBMUS, Mark
Davis/Cupertino/IBM@IBMUS, Markus Scherer/Cupertino/IBM@IBMUS, Raghuram
Viswanadha/San Jose/IBM@IBMUS, Steven R Loomis/Cupertino/IBM, Syn Wee Quek/San
Jose/IBM, Vladimir Weinstein/San Jose/IBM@IBMUS, Steven Atkin/Austin/IBM@IBMUS
From: Mark Davis/Cupertino/IBM@IBMUS
Subject: Re: Fw: y G

Steven and I were discussing this, and came up with an idea. It would

ensure that whatever was formatted would also parse correctly back to the same
thing – IF given the same pivot.
would allow single digit output, which we should have for Japanese
would ensure that all years can be parsed (right now, 8 AD can't be parsed
correctly)
the output appears reasonable (1700 formats as 1700, not 00)

Old behavior is that y and yyy behave the same as yy, and otherwise the number
of y's is the minimum and maximum digits (except for 4 years).

The idea is that you
a. produce at least as many digits as there are y's, and
b. produce as many more as you need to disambiguate given the pivot.

But you may get longer dates. So we may not want to do this in 2.6; we may want
to do just the pivotless single-digit case.

Examples below.

Pivot = 1930
y yy yyy yyyy
8 0008 0008 0008 0008
1008 1008 1008 1008 1008
1952 52 52 952 1952
2008 8 08 008 2008

Pivot = none
y yy yyy yyyy
8 8 08 008 0008
1008 1008 1008 1008 1008
1952 1952 1952 1952 1952
2008 2008 2008 2008 2008

Mark
___
mark.davis@us.ibm.com
IBM, MS 50-2/B11, 5600 Cottle Rd, SJ CA 95193
(408) 256-3148
fax: (408) 256-0799

Steven R Loomis
2003.05.22 17:26

To: Mark Davis/Cupertino/IBM@IBMUS
cc:
From: Steven R Loomis/Cupertino/IBM@IBMUS
Subject: Fw: y G


Forwarded by Steven R Loomis/Cupertino/IBM on 05/22/2003 05:26 PM ----- Steven R Loomis
05/22/2003 05:22 PM
To: Alan Liu/Cupertino/IBM, Doug Felt/Cupertino/IBM
cc:
From: Steven R Loomis/Cupertino/IBM@IBMUS
Subject: y G

JapaneseCalendar is passing all the calendar regression tests from java and some
new ones. I'm working on writing format tests now.

8 Showa formatted as " y G" comes out as "08 showa" because we really check
for >=4 or <4 number of digits.

y -> 08
yy -> 08 (truncated)
yyy -> 08
yyyy -> 0008

I would like just 'y' to format with no padding and no truncation. ( just as
'M' does).

That way years like 8, 88, 888, 8888 appear as is.

our Java Japanese Calendar Symbols data has a 2 digit year (yy) , is this
correct?

ex: http://www.forest.dnj.ynu.ac.jp/~mori/MExperiment/Nurikabe/report.html
(Heisei 9

in Japanese the Google war results are:

平成08 ..-> 338,000 hits
平成8  2.2 million

平成02 471,000
平成2 2.9 million (top ranking: Adobe Illustrator Heisei 2 =
Illustrator '90 !)

-s

Environment

Status

Assignee

Steven R. Loomis

Reporter

TracBot

Labels

Time Needed

Hours

tracCreated

Jul 03, 2003, 11:18 PM

tracOwner

srl

tracProject

ICU4C,ICU4J and ICU4JNI

tracReporter

mark.davis@63ab4e4d4e2312f9

tracResolution

fixed

tracReviewer

yoshito

tracStatus

closed

tracWeeks

0.2

Fix versions

Priority

critical