ICU Meeting Minutes 2007 (Archived)

Current Meeting Minutes

2007/12/19 Agenda

  1. ICU 4.0M1 (3.9.1) status (George & Yoshito)
  1. Plurals (Mark)
  1. Next meeting: 2008-jan-09

2007/12/12 Agenda

  1. ICU 3.8 timezone warning in ICU4C/ICU4J 3.8 readme? Is it all still correct? (George)
  1. ICU 3.8.1 status (George)
  1. Backward string search (Eric)
  1. ICU4C: move public headers to install/unicode/ and install/layout/, remove build step on Windows (Markus)
  1. CLDR 1.5.1 (Mark)

2007/12/05 Agenda

  1. Status of ICU 3.8.1 (George & Yoshito)
  1. Memory leaks, uninitialized memory, crashes and other Purify/valgrind errors for ICU4C.
  1. Purify reports memory leaks, Yoshito applied a fix and is testing with Purify again
  2. Ubuntu x64 crashes in tests; blocks valgrind testing
  3. BiDi code access to uninitialized memory
  4. BreakIterator memory leak
  5. Steven, Yoshito & Dave will run valgrind
  1. There is a lot of brand new timezone code. An additional reviewer for the new code for thread safety and other issues is needed due to short deadline.
  2. Some mismatch in Calendar fields (leap month) between ICU4C and ICU4J; currently ICU4J cannot directly use data generated from current ICU4C. Yoshito to fix asap. Real fix to be done after 3.9.1 tag.
  1. Apple ICU representation
  1. Peter Edberg taking over most of Apple ICU work. Deborah remains somewhat involved.
  1. z

2007/11/28 Agenda

  1. Propose moving the 3.8.1 release from December 1st (Saturday) to December 3rd (Monday) or a later date (George & Yoshito)
  1. DateFormat performance: ICU4C in some cases up to 3x slower than ICU4J, Yoshito is profiling
  2. Lloyd Honomichl joining IBM ICU team

2007/11/14 Agenda

  1. Propose canceling next week's meeting on Wednesday the 21st.  (George)
  2. 3.8.1 ticket list (Yoshito)

2007/11/07 Agenda

  1. Server transition (Michael)
  1. String search bugs (Christine, Eric, Andy)
  1. BiDi problems (Deborah)
  1. CLDR 1.5.1 (Mark)

2007/10/31 Agenda

  1. Set the minimum Java platform to JDK 1.5? continuation
  1. The part needed for Eclipse RCP and adheres to its restrictions (includes DateFormat which should get updated to new JDK features)
  2. The rest of ICU, using JDK 1.5 features
  1. Metazone discussion from last time: Briefly review with John & Mark present, and reconfirm consensus
  1. CLDR agreed on for 1.5.1
  2. Overall, CLDR has the following for 1.5.1 (relevant for 3.8.1)
  4. Consensus confirmed
  1. Regular expressions (Andy)

2007/10/24 Agenda

  1. Unicode conference discussion? How was it?  (George)
  1. Should all the papers be posted on
  2. George to collect papers and prod people
  1. metazone data maintenance policy (John/Yoshito)
  1. Design change in metazone data
  1. move out from root.res (plan)
  2. metazone boundary data changed from specifying boundary times in local wall time to specifying them in GMT (done in both CLDR & ICU)
  3. Move metazone data to new file, metazone.res, not into supplemental.res
  1. tzdata2007h changes metazone mappings, causes inconsistent date formatting if only the zoneinfo.txt file is update but not the metazone data
  2. There is a test which can detect this problem among others, although it often generates 1000s of errors.
  3. 3.8.1 to correct the issue - won't provide data update for 3.8. (Consensus)
  1. Settle on 3.8.1 items
  1. What fixes will be included?
  1. TimeZone formatting/parsing
  1. ICU4J Calendar handles ambiguous local time differently from Java
  2. Localized GMT string for time zone display name
  3. Parsed time zone is not properly set in the result calendar
  4. Date Formatting: ZZZZ formats incorrectly
  5. VVVV (and V) fail to parse in timezone formats
  6. TimeZone GMT format to handle a offset with a fraction of minute
  7. TimeZone.getTimeZone(timezone) fails for GMT+8:30 (although spec'ed)
  8. Metazone information needs to be GMT
  9. SimpleDateFormat parse to round trip time properly
  1. ICU4J Charset? No
  2. ICU4J BiDi issue - #5961
  3. new timezone headers in MSVC proejct - #5994
  4. DateFormat serialization test in ICU4J - #5902

2007/10/10 Agenda

  1. George & Steven moving off ICU. Michael to continue to do ICU server maintenance.
  2. Plans/ideas for ICU 4.0 (after tickets are fixed)
  1. Owners to fix their ticket categorizations by Sept 28. See latest email from Markus this morning.
  2. Types, priorities, weeks, components, owners, remove RFE/ONGO (see 2007-09-26 minutes and icu-core emails)
  3. Release planning: Distinguish whether we think a ticket is likely to make it for the next release. Use "candidate" milestone vs. low/high priority vs. accepted state?
  1. Google ICU 4.0 initial areas of interest:
  1. Proposal to use feature branches for all "large" or "disruptive" changes. (Markus)
  1. Subversion file properties (George & Steven)
  1. Related to
  2. Everyone should make sure that their client's autoprops be configured.
  3. Michael to add server-side hook to verify that new files have the correct svn properties.
  4. Andy to update sample svn config file documentation.

2007/09/26 Agenda

  1. Trac update, server migration (Steven)
  1. Updated docs in private area (members-only area) with server config
  2. Plan is to keep htdocs content in sync, and set up new server as a sandbox for testing ( trac, svn )
  3. New server has done well for downloads, etc.
  1. Is dedicated core 2 duo; solves problems of load, access, only old Java, enables tomcat, more disk space. Fedora core linux
  1. Inbound mail disabled normally
  2. After transition to new server, will have an experimental trac 0.11 server as well
  1. 0.11 has approved template system, easier to customize, performance, different states of bugs (review)
  2. SQL still works
  3. Still experimental, no timeline for release yet; so this is just a sandbox
  1. Everyone should try out.
  1. Set the minimum Java platform to JDK 1.5?
    Source syntax features (generics, for loops, boxing, etc) and binary format. Match the API for new methods. There would be two streams:
  1. Proposal1: branch
  1. ICU3.8.x with bug fixes and new identifiers, timezones, etc. but minimal other changes. Works with JDK.1.4/1.3
  2. ICU4.0+ new features, requires JDK1.5 (Java 5)
  1. Eclipse core uses 1.3 API subset, doesn't need any new features; But other clients also use 1.4 API use in downloads.
  2. Can we segment into parts that use different JDKs? Can then make plugin with different requirements.
  3. There is a clear ongoing demand for ICU4J from Eclipse. Given that, how do we maximize the use of our engineering resources?
  4. Everyone also understands the value of moving to Java 5, both in terms of increased internal robustness and in matching APIs, and in usability.
  5. Yoshito needs more time to investigate the packaging options in Eclipse.
  6. Eclipse is planning for 3.4, June 2008. See whether they have a timeline for updating.
  1. Trac tickets need cleanup for better planning (Markus)
  1. Owners to fix their ticket categorizations by Sept 28, according to Markus's email modified as by the below.
  2. Use "enhancement" instead of "RFE:" for feature enhancement. Stop adding it, ignore in existing, clean up if owners want to.
  3. Use "task" for anything that isn't a bug or feature enhancement, such as performance testing, or adding new tests unassociated with bug or feature.
  4. Add "ongoing" as a type, make all "ONGO:" be "ongoing". Owners to change.
  5. At the start of the release, each ongoing ticket is cloned as a "task" with a target of the current release. Owners to change.
  6. Also
  1. Andy to take 3.8 closed bugs out of spreadsheet view.
  2. Markus to update ticket lifecycle.
  1. Plans/ideas for ICU 4.0

2007/09/19 Agenda

  1. Post Mortem (George)
  1. Congratulations!
  2. What worked well?
  1. George as driver
  2. Coordination worked well -- spreadsheet (for who's doing what) and agenda
  3. CLDR integration worked well, John did a lot of good work ahead of time.
  1. What didn't work well?
  1. Lots of last minute work
  2. Didn't finish all the bugs we wanted to get done
  3. Everyone wants more frequent releases
  4. Lots of last minute problems with timezones
  1. ICU 4.0 planning (George)
  1. Coordination of work
  2. What are the big features planned for the next release?
  1. George to solicit feature requests
  2. People to canvas in their companies
  3. Discuss at next few meetings
  4. Send a note to icu-core for the record of your planed features
  1. General agreement on release schedule
  1. ICU 3.8.1? (Yoshito)
  1. Do we really need to release 3.8.1 for time zone formatting/parsing? yes
  2. If so, what problems should be fixed? yes, need proposal
  1. Parsing 'V'
  2. Date roundtrip
  3. Always set parsed TimeZone in parse method with Calendar argument
  4. Others??
  1. Any other issues?  (ICU4J Charset?), yes
  1. ICU4J API status version (Yoshito)
  1. Yoshito incorrectly updated JavaDoc status tag in 3.8 - for example, @draft ICU 3.4 -> @stable ICU 3.8
  2. Already corrected in trunk.
  3. Should we update the online API ref doc with the corrected version? no, wait for maintenance
  4. Why don't we use the standard JavaDoc tag - @since for the purpose? Yoshito to check on semantics
  1. Making the agenda public again (Mark)
  1. remove phone number from this document
  2. copy contents to fresh, public document (readable by world, editable by core)
  3. that will be the document we update
  4. if the doc gets too large, archive older months
  1. Random updates from Steven
  1.   - SVN 1.5 merge tracking webinar
    ( TicketList and DcutHelper on main trac page )   - Srl Trac homepage  - copyright scan  - demos
  1. Trac update, server migration (Steven) next week
  2. Set the minimum Java platform to JDK 1.5? next week

2007/09/12 Agenda

  1. Reading U_RBBIDEBUG can cause a SecurityException in ICU4J (Yoshito)
  2. security.policy used for 'secure' test allowed the property access, but it should not.
  3. The problem was introduced in 3.6, not a regression problem.
  4. Steven found it while trying to load ICU4J for web demos.
  5. Yoshito fixed this today, proposing to merge into 3.8.
  6. Consensus to merge into 3.8.
  1. trac update (Steven)
  1. Open reviews and tickets (George)
  1. Are we ready to release on Friday? (George)
  1. Warning message on timezones (Mark)

WARNING - in ICU 3.8, the behavior of date formatting and parsing has changed significantly, perhaps requiring recoding on your part depending on your usage. The goal of making the change was to return more understandable results from formatting timezones, but a byproduct is that the result from formatting with strings z, zzzz, v or vvvv are no longer unique, and thus no longer roundtrips. That is, if you use a date format with one of these strings, producing a certain output, you can no longer parse that output and expect to recover the original timezone.

What you will be able to get is a related, "best fit" mapping for the name, based on the region associated with the current locale and the mappings found in CLDR's supplemental data: for example, if you format the time zone "America/Denver", getting "Heure des Rocheuses" in French, and then parse, the resulting time zone would be "America/Denver" unless the locale in use has the region "CA" (such as en-CA or fr-CA), in which case "America/Edmonton" would be retrieved.

If you require roundtripping, you will need to change your code to use "VVVV" instead. If you are working with date patterns based on a locale, then the workaround is to use the DateTimePatternGenerator to convert the format you get for a locale to using "VVVV". [Insert code snippet].

  1. Eclipse with ICU4J (Yoshito)

2007/09/05 Agenda

  1. Timezones (John and Mark)
  1. All agreed on 3.8: John to fix timezone so that zones without daylight maps to "standard" string
  2. Setting calendar: 3.6 code didn't always set timezone in parsing, also sometimes set the internal calendar when it shouldn't
  3. Everything should work after 1970 -- that's our cutoff.
  4. Still leaves some significant problems: open issue as to whether we want a 3.8.1 or not.
  5. -- full list -- suppressing daylight -- suppressing daylight and differences < 1 day -- log of contents of metazones, listed by metazone, and by zone
  1. ICU bug reviews (George)
  1. Open 3.8 reviews
    ajmacher  0
    andy      11
    claireho  1
    dbertoni  1
    deborah   9
    doug      2
    emmons    2
    eric      2
    grhoten   2
    mark      13
    markus    8
    michaelow 1
    srl       3
    weiv      2
    yoshito   0
  2. Open 3.8 tickets
    ajmacher  0
    andy      2
    claireho  0
    dbertoni  0
    deborah   0
    doug      9
    emmons    8
    eric      0
    grhoten   10
    mark      11
    markus    4
    michaelow 6
    srl       9
    weiv      4
    yoshito   2
  3. Everyone can do their reviews except Deborah and Mark, who need help. (Mark won't be doing any other bugs, got sucked up into findingmetazone problems).
  4. Problem with commits under a bug that didn't get done in the release
  1. Release (George & Yoshito)
  1. Overall, release is going well.
  2. Reminder, George is off Friday
  1. Collation (Mark)
  2. Will put discussion under ticket 5913. (will use {...} to prevent formatting)

2007/08/29 Agenda

  1. Timezones (John and Mark)
  1. John to fix code so that z, zzzz, v, vvvv, V, VVVV always set the zone on the calendar.
  2. Mark to file bug (
  3. Mark to send to announce/design, and in the readme, that there is a radical change to behavior, and people may need to change code.
  4. Mark to propose edit to TR35 (
  1. Are we ready for ICU 3.8 d02 release on Friday? (George)
  1. Yoshito states there are some issues in ICU4J, but everything should be fine for releasing by noon Friday.
  2. Only crashing bugs should be fixed after d02.  Minimal change should be done after d02.
  1. DCUT Helper (Steven)

2007/08/22 Agenda

  1. u_terminateChars on pure DBCS and QBCS encodings not working (George)
  2. ICU4J build script changes (Yoshito)
  3. ICU task list (George)
  1. Will add collaborators
  2. ICU4J/C: running the "builds without data" (Eric will do)
  3. removing test data portability
  4. posting news (Mark to do)
  5. Add column of item numbers for reference (George)
  6. Please do reviews by friday.
  1. CLDR features not in ICU (Mark)
    System.out.println(ULocale.getDisplayName("en_GB", "en")) => "English (United Kingdom)"
    while CLDR: <language type="en_GB">British English</language>
    Bug 5650 is assigned to Deborah, presume it will be done in 4.0
  2. Status for release (overall, pretty good shape, but more problems to track down)
  1. Known crashes for ICU4C (George)
  2. Known crashes for ICU4J (Yoshito)
  1. Friday pm creating candidate d02; everything is under change control afterwards.


  1. Ambiguous local time at DST onset (yoshito)
  1. Input to Calendar or to DateFormat parsing: 2007-03-11 2:30AM PT is interpreted as 2007-03-11 1:30AM PST
  2. Incompatible with Java - - Java gives 2007-03-11 3:30AM PDT
  3. TimeZone#getOffset(long date, boolean local, int[] offsets) is used in Calendar implementation
  4. When date = <local milliseconds for 2007-03-11 2:30AM>, local = true, getOffset returns raw = <-8 hr> and dstsavings = <1 hr>.  So getOffset for 2007-03-11 2:30AM in PT is in DST.
  5. date+offsets[0]+offsets[1] != UTC.  If getOffset returns raw = <-8 hr> and dstsavigs = <0 hr>, then date+offsets[0]+offsets[1] == UTC is always true and Calender should work like Java.
  6. Same in ICU4C. See test cases showing ICU's behavior in
  7. Do we want to -
  1. change the calendar behavior and make it compatible with Java?
  2. change the behavior of getOffset(long, boolean, int[]) [this is not parallel with the JDK] or to add a new API to support the behavior (could be yet another option in the API which Markus recently  proposed for ambiguous time support)?
  1. Consensus to make Calendar and DateFormat parsing behavior consistent with Java.
  2. We should check Olson localtime() behavior.
  3. Consensus that getOffset() and Calendar should agree on whether a point in time is DST. As result, don't change getOffset().
  4. Yoshito and Markus should revisit the recent getOffset() proposal and consider documentation or additional API (enum) to address the spring-forward non-existent times.
  5. Fix Calendar after ICU 3.8.
  1. Extended Combining Character Sequence break iterator, Extended Grapheme Cluster.  We need to remove Extended Grapheme Cluster.  We can either rename it to Extended Character Sequence or remove it altogether. (andy)
  1. Mark: Yank it because it's not yet implemented in Java anyway.
  2. Mark & George: Yank it because UTC could change it again.
  3. Consensus to yank it.
  1. Help with the BRS items (George)
  1. George will be creating a Google doc with assignments.
  2. Volunteer for sample testing? Yoshito -> ICU4J Dave -> ICU4C
  3. Volunteer for updating @draft to @stable in ICU4C?  George
  4. Volunteer for API change report in ICU4C? George
  5. Volunteer for running testmap? (probably a non-issue) Andy
  6. Is Dave working on hdrtest and verifying memory allocation functions? Yes.
  1. How's the d02 release going? (George)
  1. Will the ISO-2022 converter go into ICU4J?  Andy says not going to make 3.8 release.
  2. Please do your reviews.  Here are the number of reviews left.
  1. Andy - 11
  2. Deborah - 7
  3. Doug - 1
  4. John - 0
  5. Eric - 4
  6. George - 10
  7. Mark - 5
  8. Markus - 6
  9. Steven - 30
  10. Vladimir - 0
  11. Yoshito - 2
  1. Please assign reviewers if you're done with your tickets.
  2. Start change control and 3.8 branch on August 22nd?
  3. Agreed on the 24th for starting change control.
  1. Consensus to add
  2. Document as user-defined
  3. ICU will not use the 4th version number field for future releases
  1. static const int32_t gMaxIntegerDigits = DBL_MAX_10_EXP + DBL_DIG + 1; change.  George to propose to icu-design.


  1. ICU 3.8 release status update


  1. ICU 3.8 D01 release today?  Are we there yet? (George)
  1. The icu-design list seems a little too lively to freeze the API.
  2. DateTimePatternGenerator not quite there. Possibly merging into trunk today.
  3. Mark to make some @internal changes for ICU4J
  4. Ticket 5817 for modifying ICU4J DateTimePatternGenerator, TBD for d01
  5. ICU4J release notes about supported platforms (IBM reference platforms) — IBM to update set of platforms (operating systems)
  6. Move d01 to Friday? Consensus
  1. Change in full time format pattern (Yoshito)
  1. In CLDR, full time pattern uses 'v' for time zone since 1.4
  2. The pattern letter 'v' is not available in Java.
  3. ICU4J users did not see much difference from Java until now, because time zone strings resolved by 'v' was equivalent to 'z' before we actually use generic time zone names in ICU.
  4. With ICU 3.6, US pacific time zone is displayed as "PST" or "PDT" with the full pattern.  With ICU 3.8, it will be "PT".
  5. For major locales, time string formatted by Java DateFormat with DateFormat.FULL pattern can be parsed with ICU4J DateFormat with DateFormat.FULL, or vise versa.  Although this is a bad assumption (this does not work well for all locales even with ICU4J 3.6), the change in ICU4J 3.8 may break existing application.
  6. John concerned to use 'v' in some places and 'z' in others, but Mark and John arrived at compromise data.
  7. John surprised that short 'v' was used in full formats rather than long 'vvvv'.
  8. John: Future CLDR time formats might be different; users might want full format but different choices for time zone.
  9. John is ok with current state for the short term.
  10. Yoshito ok with it as well. Understand desire to do better job than Java, resulting in incompatibilities.
  11. John to submit CLDR bugs to a) fix 'v' to 'vvvv' and to b) start discussion about longer-term issues; possibly desire keyword for different styles of time zone formats?
  1. No-data test case issues (Yoshito, Doug)
  1. At this moment, ICU4J noData test case is failing for a BiDi test case.  The problem is caused by static initializer in the BiDi test case.  The initialization code try to update the test class's own property table and calls a static method in UCharacter.  But the static method in UCharacter throws MissingResourceException.  This problem can be removed (actually, skip the test case itself) by calling the initialization method in each test case.
  2. I resolved the problem above locally, but I encountered next issue in another test case.  Resolved it, then another and so on.
  3. The root cause of some issues are static initializer in both test code and ICU library code.  Some ICU class cannot be loaded because of initialization failures.  There are two typical cases below -
  1. noData target in ICU4J runs standard test cases without data at all (no root locale data, no Unicode data, no nothing..).  When -nodata is passed as the argument of test framework code, it just produce warning when MissingResourceException is thrown by each test case.
  2. Many ICU i18n service classes cannot be instantiated without ICU data.  For example, it fails to create Calendar instance without ICU data.  Although there were no test failures reported fornoData test in ICU4J 3.6, 1176 test cases were failing into this situation.  Not a small numbers of test cases encounters MissingResourceException before executing the most of code in each test case - typically, when creating a target test object.
  3. It is doable to remove the test failures, but what we are testing with this is really questionable.
  4. We do not have clear policy about static initialization.  Any failure in static initialization code will result NoClassDefFoundError.  Some classes are tightly bound to ICU data (for example, some basic classes definitely require Unicode data files).
  5. At this moment, ICU data is a part of ICU4J library (icu4j.jar).  The ICU data generation tool also include "mandatory" data set always.  So, it's not clear about what we want to achieve with "noData" test.  Don't we actually want "minimum data test"?
  6. I do not know about ICU4C's story for "noData" check.
  7. Clear that we want the no-data test in ICU4C, don't just want to crash.
  8. Not clear about Java. Nice to get MissingResourceException, but class loader exception not so bad either.
  9. Difference: ICU4J packages its data; a user has to go out of their way to remove it. This is in contrast to ICU4C, where it is very easy to not have it set up to find its data.
  10. Yoshito: There is a set of minimum/mandatory set of data (e.g., Unicode properties). We could test that with this minimum set we would not getMissingResourceException. (This is a more likely scenario for ICU4J, for data customization.)
  11. George describes log_data_err() in C tests.
  12. Mark: Not good enough to check just for MissingResourceException. Lots of work to change whole test suite to test no-data in ICU4J.
  13. Andy: Could make a small set of tests that verify certain no-data behavior.
  14. Doug: Static initializers should succeed or at least throw a sensible exception.
  15. Markus: Simply test no-data for whether we get MissingResourceException, NullPointerException, ClassLoadException. Ignore all other failures.
  16. Doug: This ought to work with minimum data, rather than no data at all.
  17. We could define the minimum set of data as that set that causes us to not break static initializers...
  18. Minimum set should include Unicode properties, root locale, but not collator root, etc.
  19. Don't fix for ICU4J 3.8. TODO for ICU4J 4.0: Define minimum set of data, run tests against that, check for small set of undesired exceptions.
  1. Transliterator status (John)
  1. Are there issues with listing charsets in the alias table that don't exist in ICU by default? (George)
  1. I don't think there were issues when this was mentioned previously.
  2. This is helpful when adding conversion tables to ICU through the Data Library Customizer
  3. Maintaining a separate alias table isn't required when the aliases are added to ICU by default.
  4. Reduces guesswork on how conflicting aliases are resolved.
  5. Users might be surprised by the new difference between ucnv_openAllNames and ucnv_getAvailableName. They currently return the same list by default.
  6. George won't add all names for charset repository, only unique ones, e.g.: GSM, DBCS. Not adding more variations of Shift-JIS which would cause conflicts with existing alias-canonical name mappings. To be ready for d02.


  1. JDK Locale th_TH_TH vs. ICU4J ULocale th_TH@calendar=buddhist (Yoshito)
  1. Anyone opposed to U_TITLECASE_NO_BREAK_ADJUSTMENT? (Markus)
  1. ICU 3.8 d01 (George)
  1. Any remaining API proposals?
  1. Version 3.7 -> 3.8 change should happen today or tomorrow.
  2. Please assign reviewers
  3. Please do your reviews
  4. BRS
  1. CLDR data testing status? (John & Steven)


  1. UnicodeSet proposal (Mark email 20070627)
  1. CLDR data coverage and testing
  1. ICU 3.8 d01 status (George)
  1. People working away on tasks...
  1. New API proposed for ICU4J charset conversion, similar to ucnv_openPackage(), to open application-provided converters - ok


  1. Modularization (Yoshito)
  1. Lotus did a presentation on this subject at IUC 26.
  2. Doug says that Google discourages modularization of ICU4J.
  3. George says that separating conversion tables into the charsets jar might help, but it would make it more difficult simply use the data from the Data Customizer.
  4. Yoshito says that CollectionUtilities dependencies will be handled by Yoshito, and was agreed by Mark.
  1. Timezone (Yoshito)
  1. email 'Default TimeZone in ICU4J' of 2007/07/11
  2. Maintaining two copies of timezone data can be difficult for ICU4J customers.
  3. Yoshito says can we allow customers to choose whether to use Java's or ICU4J's tzdata.
  4. Doug says Java's implementation doesn't expose all the important data needed by ICU4J.
  5. Yoshito needs to investigate what private package/data dependencies are needed by ICU4J.
  6. Yoshito to close ticket 5562 due to problematic inefficiencies, dependencies and JDK differences from ICU4J.
  1. George provided an update about ICU4J charsets.
  1. Converting from gb18030 to Unicode was broken for the enumerated ranges
  2. Some error handling issues have been fixed with Andrew M and Michael's help.
  3. Doug to talk to Andy H about ISO2022 status
  1. UnicodeSet proposal (Mark email 20070627) postponed to next meeting


  1. Transform API proposal (Mark)
  1. weak pthread reference (George)
  1. M2 tasks (George)
  1. CLDR schedule (Mark)
  1. July 4th meeting cancelled


  1. Unicode 5.1 or 5.0.1? Next Unicode release won't make ICU 3.8? (George)
  1. Unicode 5.0.1 got cancelled. Unicode 5.1 will be released after ICU 3.8.
  1. ICU 3.7.2 and timebombs (George)
  1. George preparing to change the version number.
  2. George remembers perpetual time bombs, e.g. collation monkey test & transliterator.
  3. Should we just remove the test and the time bombs and just file a bug?
  4. Consensus: Permanently disable the tests (don't remove them) and file a ticket. Put ticket number into test code comment.
  1. Slip milestone 2 release? (Markus)
  1. Is milestone 2 effectively a feature freeze? Markus remembers it might, Andy thinks it is, George thinks it wouldn't be (according to internal schedule).
  2. Release schedule?
  1. M2 (3.7.2 snapshot) jun29, with CLDR 1.5 pre-release snapshot, implementation slush
  2. DCUT feature freeze (d01) aug01, with final CLDR 1.5
  3. GM (d02) aug31
  4. 3.8 release (GA) sep14 (IBM has hard deadlines)
  1. CLDR 1.5 release schedule: Release on jul15
  1. ICU 3.8 to include C wrapper for layout engine? (Eric)
  1. George: Please put the API into M2.
  2. Andy: Mark as @internal (technology preview, subject to change) because should be redesigned for real public API
  3. Andy/Eric: Ok to put in to not get lost and not maintain feature branch
  4. Consensus: Document as technology preview and mark APIs @internal
  1. Plural formatting, see proposal to icu-design (Doug)
  1. Eric: Concern about complexity for translators. Markus: Planning for translators to see single placeholder plus sub-items; longer term:UI.
  2. Eric: XLIFF 2.0 started, will propose some plural support
  3. No other off-list feedback on Doug's proposal
  1. How to mark @stable vs. @draft for new overrides of @stable superclass methods?
  1. All-new subclass: Everything @draft
  2. Existing subclass with new override of existing virtual superclass method: Mark new override @stable (match superclass stability) because users called the method already, but just got the superclass implementation
  3. Inserting new class (BasicTimeZone) into the class hierarchy (with new virtual but not abstract methods): Virtual methods that are shared between new superclass and old subclass must be at least as stable as they are in the old subclass. New superclass should be @draft unless that produces warnings when working with the old subclass.


  1. genren, urename.h and function renaming on Linux et al. (George)
  1. George could test on various machines
  2. Options -- not use genren on Linux (extra configure option)?
  3. Andy -- can we restrict the platforms. George -- IBM products needs on Window, Linux... So we can't get rid of the requirement.
  4. Key issue is on platforms that export everything.
  5. Solution: run genren only on platforms that export everything -- document this as a tool requirement.
  1. charsets.jar (Yoshito)
  1. General policy for SPI
  2. Ideally, user has option of: A. changing JDK behavior alone, B. using the new charsets with ICU API alone, C. Both, D. Neither (no new charsets).
  3. Currently only support A and C, with D as build option
  4. Leave as is.
  5. Separating data from code (longer term), and separate out SPI hook from everything else.
  1. Timezone issue (Deborah)
  1. George will work with Deborah


  1. Review action items
  2. George implementing U_STRING_DECL, UNICODE_STRING, etc. with direct UTF-16 string literals for more compilers.
  3. CLDR schedule (Mark), and schedule for integration into ICU (John)
  1. Mark has proposed a CLDR feature for a new type of break iteration: Cluster breaks. Andy: Need to discuss whether break iteration data comes largely from theUAX or from CLDR.
  2. Java charset conversion code status (Andy)


  1. Review action items
  1. George collecting 3.8 M2 at-risk items (continue to send feedback to icu-core)
  2. 3.8 M2 target date: end of June
  1. String search status (Andy)
  1. Existing implementation has many bugs, will take considerable time to fix
  2. Won't fix current Boyer-Moore implementation short-term, won't replace with different algorithm short-term
  3. Added new function as a workaround, designed to be patchable into 3.4 and 3.6; need to decide internal vs. public; uses general API (StringSearch object, setters, getters, etc.) and collation code but not much of other existing StringSearch implementation code; new test file, otherwise changing existing files.
    Slower than Boyer-Moore but works correctly (or does not have the same bugs...)
  4. Need to figure out what to do long-term
  1. Unicode: Future uppercase sharp s character ("uß" here) vs. casing stability
  1. Rationale for new character: Sharp s means something slightly different from ss, especially in new German orthography
  2. ß case-folds to ss, uppercases to SS
  3. New uß will lowercase to ß and case-fold to ss
  4. Debate about whether to change uppercase of ß to uß (Microsoft wants this change now if UTC ever might make this change)
  1. PMC team members
  1. PMC members according to John, Steven, Mark, (Markus), Andy, Deborah, Tex
  2. Doug missing from the page: Mistake
  3. Markus listed as PMC member: Mistake
  4. All PMC members present except Tex
  5. Motion by Mark to add Yoshito to the PMC, Steven seconded. Unanimous.
  6. Motion by Andy to replace Andy with Markus on the PMC, Mark seconded. Unanimous.
  7. Current PMC members: John, Steven, Yoshito, Mark, Markus, Doug, Deborah, Tex


  1. Review action items
  2. Google visit
  1. 10:30am Pacific Time on May 23
  2. Markus to send instructions
  1. CLDR - John
  1. Draft status discussion.  What is in ICU by default.  Where do we draw the line?
  2. icu/source/data/icu-config.xml can be used to modify the default list.
  3. Contributed or higher should be the default for ICU.  John to implement change.
  4. Supplemental Data discussion.  ICU doesn't read this right now.
  5. Trac #4283 will be used to make ICU 3.8 read the supplemental data for currency information.
  1. Data customization tool status - George


  1. IUC 31 session acceptance. See
  1. Andy's Unicode Conference presentation acceptance?
  2. Doug's Unicode Conference peresentation acceptance?
  1. Do we want to release ICU4JNI 3.8?
    The current amount of effort to release ICU4JNI isn't quite
    justified by the perceived demand of ICU4JNI, and IBM is short staffed. The new ICU4J charset API will also make ICU4JNI less meaningful.
  1. No we don't want to release ICU4JNI 3.8
  2. Have as a legacy release
  3. Still have the download page but state that ICU4JNI is inactive
  4. Migration docs specifies to use ICU4J
  5. Not actively providing 3.8 support for ICU4JNI but will if customers need it
  1. ICU4PAS
    Several ICU developers were recently contacted about creating this project. Do we care about the naming? Does it dilute the ICU brand name? More programming language specific ICU wrappers are fine by me. It creates a larger community. Should we create a web page that lists available ICU wrappers Should it be
  1. Have link to other related projects to ICU
  2. Send an email to ICU4PAS saying about our discussed link to other projects
  3. Do whatever that will minimize the time we are spending on it.
  1. ICU 3.8 M2 status
    Please review your task list, and verify that you're on track for the M2 release.
  1. M2 release is currently Mid-June
  2. Send email to icu-core list for everyone to check task list before next Wednesday
  1. Others
  1. May 23rd meeting at Google site at 10:30 AM.


  1. String search
  1. Mark and Vladimir discussed
  2. May simplify API
  3. Andy's doing short-term fix, removing BM.
  4. Vladimir is looking at longer-term fix.
  1. Data compatibility
  1. Major and Minor version the same, means the data can be used.
  1. New code and new data may be added, but new code can continue to use old data.
  1. Scenarios
  1. new code, old data; want to detect, probably installation error.
  2. old code, new data; common case (updating timezone data).
  1. Proposal:
  1. Stamp the data with a new version number, the full data version: major, minor, update
  2. When the code is built, burn in the full-data version.
  3. Clients can access the code's full data version and the data's full data version, and detect differences.
  4. Have convenience API to detect that old data is being used.
  1. Discuss bucket?
  2. Eclipse update -- now available! Try out if you have Eclipse 3.2.2
  3. Please continue to try out server!


  1. ICU4J 3.6.1  This is the version of ICU4J that will be bundled into the upcoming Eclipse release; it also fixes a critical problem with a failure to load some locale data. Yoshito has it ready to release. Agreed to do (April 30).
  2. Proposed face-to-face ICU meeting on May 23. Google could host. (In that case, meeting a little earlier, 10:30-11:30, would make lunch a little easier.) (Markus) Agreed.
  3. Data stability policy for ICU maintenance releases (George)
  1. Backwards & forwards compatibility of data format (not contents) when major/minor are the same. Can add data and structure; just can't break previous code. Agreed.
  2. Existing policy requires binary compat only.
  1. String Search Bugs.  Serious, non-trivial problems.  Need to decide how to address.  (Andy)
  1. Why the 's' in static .a libraries? (libsicudata.a vs. (Markus)
  2. Agreed to file bug, investigate change (Linux, Windows, AIX are involved)
  1. server change, testing, SSL (Michael, srl)
  1. New server available for testing -- try it out (see email)
  2. Will allow authenticated logins
  3. New server will be wiped, so you can try out anything you want.
  4. Plan to migrate within week or two. Send problems to michael.
  1. icu tz updater (srl)
  1. Look at external download page.
  2. Searches for installations of ICU4J and updates tzdata.
  1. Staffing for ICU (Deborah)
  1. Problems that we'd like to address, items deferred. Could see bit-rot
  2. Organizations focus on the items that are important to that organization
  3. Each organization contributes 10% to "general health"?
  4. Come up with estimate, that we can take back to our management.
  5. Ongoing work - handling incoming bugs.
  6. Take up again in next meeting.
  1. Is this way of doing the agenda working? Agreed.
  1. Andy to add snapshot to
  1. <add items here>

Past Meetings