Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Add guide to the EDR

  • Loading branch information...
commit eb8525d77fd1fe9c8ec2a79f760e3ca968df25c7 1 parent 8258b96
@jodastephen jodastephen authored
Showing with 1 addition and 0 deletions.
  1. +1 −0  admin/edr2/JSR-310-guide-0.7.html
1  admin/edr2/JSR-310-guide-0.7.html
@@ -0,0 +1 @@
+<html><head><title>JSR-310 Specification v0.7</title><style type="text/css">ol{margin:0;padding:0}.c1{padding-left:0pt;padding-top:0pt;direction:ltr;margin-left:30pt;padding-bottom:0pt}.c0{padding-top:0pt;height:10pt;direction:ltr;padding-bottom:0pt}.c12{list-style-type:disc;margin:0;padding:0}.c4{padding-top:0pt;direction:ltr;padding-bottom:0pt}.c6{max-width:468pt;background-color:#ffffff;padding:72pt 72pt 72pt 72pt}.c5{padding-top:0pt;direction:ltr}.c10{font-size:11pt;font-family:"Arial"}.c17{color:inherit;text-decoration:inherit}.c22{color:#1155cc;text-decoration:underline}.c2{color:#0000ee;text-decoration:underline}.c21{padding-left:0pt;margin-left:36pt}.c11{height:14pt}.c19{font-size:14pt}.c20{font-size:24pt}.c15{padding-bottom:12.8pt}.c7{padding-bottom:12pt}.c18{direction:ltr}.c3{font-weight:bold}.c14{font-size:18pt}.c16{padding-bottom:11.2pt}.c13{text-align:center}.c9{font-style:italic}.c8{height:10pt}.title{padding-top:24pt;line-height:1.0;text-align:left;color:#000000;font-size:36pt;font-family:"Verdana";font-weight:bold;padding-bottom:6pt}.subtitle{padding-top:18pt;line-height:1.0;text-align:left;color:#666666;font-style:italic;font-size:24pt;font-family:"Georgia";padding-bottom:4pt}li{color:#000000;font-size:10pt;font-family:"Verdana"}p{color:#000000;font-size:10pt;margin:0;font-family:"Verdana"}h1{padding-top:12pt;line-height:1.0;text-align:left;color:#000000;font-size:18pt;font-family:"Verdana";font-weight:bold;padding-bottom:12pt}h2{padding-top:11.2pt;line-height:1.0;text-align:left;color:#000000;font-size:14pt;font-family:"Verdana";font-weight:bold;padding-bottom:11.2pt}h3{padding-top:12pt;line-height:1.0;text-align:left;color:#000000;font-size:12pt;font-family:"Verdana";font-weight:bold;padding-bottom:12pt}h4{padding-top:12.8pt;line-height:1.0;text-align:left;color:#000000;font-size:10pt;font-family:"Verdana";font-weight:bold;padding-bottom:12.8pt}h5{padding-top:12.8pt;line-height:1.0;text-align:left;color:#000000;font-size:8pt;font-family:"Verdana";font-weight:bold;padding-bottom:12.8pt}h6{padding-top:18pt;line-height:1.0;text-align:left;color:#000000;font-size:8pt;font-family:"Verdana";font-weight:bold;padding-bottom:18pt}</style></head><body class="c6"><p class="c0 c13"><span class="c10"></span></p><p class="c4 c13"><span class="c3 c20">JSR-310 Draft Guide</span></p><p class="c0 c13"><span class="c3 c14"></span></p><p class="c4 c13"><span class="c3 c14">Date and Time API</span></p><p class="c4 c13"><span class="c3 c14">Version 0.7.0 (EDR2)</span></p><h2 class="c5 c11"><span></span></h2><h2 class="c5"><span class="c9">NOTE: JSR-310 is expected to be provided as part of JDK-8. As such, there will probably be no explicit specification for the JSR beyond the Javadocs. This guide, formerly the specification, is intended to introduce the API for the purpose of review.</span></h2><h2 class="c5"><span class="c3 c19">1. Introduction</span></h2><p class="c4"><span>Many Java applications require logic to store and manipulate dates and times. At present, Java SE provides a number of disparate APIs for this purpose, including Date, Calendar, SQL Date/Time/Timestamp and XML Duration/XMLGregorianCalendar. JSR improves on these APIs and covers many additional use cases needed by developers.</span></p><p class="c0"><span></span></p><p class="c4"><span>As an example, Java developers currently have no standard Java SE class to represent the concept of a date without a time, a time without a date or a duration. The result of these missing features has been widespread abuse of the facilities which are provided, such as using the Date or Calendar class with the time set to midnight to represent a date without a time. Such an approach is very error-prone - there are certain time zones where midnight does not exist once a year due to the daylight saving time cutover!</span></p><p class="c0"><span></span></p><p class="c4"><span>JSR-310 tackles this by providing a comprehensive set of date and time classes suitable for Java SE today. The API includes:</span></p><ol class="c12" start="1"><li class="c1"><span>Date and Time</span></li><li class="c1"><span>Date without Time</span></li><li class="c1"><span>Time without Date</span></li><li class="c1"><span>Offset from UTC</span></li><li class="c1"><span>Time Zone</span></li><li class="c1"><span>Durations</span></li><li class="c1"><span>Periods</span></li><li class="c1"><span>Formatting and Parsing</span></li><li class="c1"><span>A selection of calendar systems</span></li></ol><p class="c0"><span></span></p><p class="c4"><span>This document is an introduction to the full API, which consists of the Javadoc. The Javadoc and reference implementation is available at the </span><span class="c22"><a class="c17" href="">ThreeTen project</a></span><span>.</span></p><p class="c0"><span></span></p><p class="c4"><span>This draft guide is released to gain feedback. Since it is a draft, readers are advised to take care when referencing it.</span><hr style="page-break-before:always;display:none;"></p><h2 class="c5"><span>2. Date and Time terminology</span></h2><p class="c4"><span>The domain of dates, times and other temporal concepts is large and complex - much more complex than is often apparent. A key aim of the JSR is to allow the API to explain this complexity simply by the way that the features are exposed. In this way, the user of the API is guided to make the correct choice, minimising the potential for bugs.</span></p><p class="c0"><span></span></p><p class="c4"><span>Part of this process is determining and using a consistent terminology. For this purpose, JSR-310 is building upon the excellent work of the ISO-8601 standard. However, we have changed a few terms, thus the entire terminology is defined here for clarity:</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Time line</span></p><p class="c4"><span>The single line or axis of time from the past to the future.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Instant</span></p><p class="c4"><span>A single instantaneous point on the time line.&nbsp;</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Duration</span></p><p class="c4"><span>A quantity of time equal to the directed difference between any two instants on the time line.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Epoch</span></p><p class="c4"><span>A known, well-defined, instant that can be used as a reference point to measure other instants from.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Time-scale</span></p><p class="c4"><span>A system of assigning meaningful values to instants in relation to a known epoch.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Continuous time-scale</span></p><p class="c4"><span>A time-scale fundamentally based on a single incrementing number. This is usually defined as a duration relative to an epoch.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">International Atomic Time (TAI)</span></p><p class="c4"><span>The primary continuous time-scale intended for scientific and technical purposes, defined by international standard. It is agreed internationally based on atomic clocks and is completely continuous. All days have exactly 86400 seconds. The time-scale is measured in terms of the SI second unit.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Coordinated Universal Time (UTC)</span></p><p class="c4"><span>The standard time-scale intended for civil purposes, defined by international standard. It follows TAI except for the insertion or removal of an integral number of leap seconds which are intended to keep UTC closer to the real and variable length of a solar day. Most days have 86400 seconds, but some have 86399 or 86401 seconds. The time-scale is measured in terms of the SI second unit.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Simplified &quot;UTC&quot;</span></p><p class="c4"><span>A time-scale that is not defined by international standard, but is widely implemented by computer systems. This time-scale treats all days as having exactly 86400 seconds while staying in tune with UTC. This definition is, of course, not actually possible, however it is a suitable approximation for most normal computing use cases.</span></p><p class="c0"><span></span></p><p class="c4"><span>The time-scale is typically implemented by relying on the fact that clocks in most computers are not accurate and the functions that tell the time are loosely specified. One approach is to slow time down around a leap second, a second is to make time go back one second, while another is to make the system hang for a second.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS)</span></p><p class="c4"><span>A </span><span class="c2"><a class="c17" href="">internet draft</a></span><span>&nbsp;that defines a way to map UTC (with leap seconds) to simplified &quot;UTC&quot; (without leap seconds). The approach smooths leap seconds over the last 1000 seconds of the day. This provides an exact mapping between a highly accurate clock and the form of time that is useful to computer programmers. This approach, like any that changes the meaning of the second, is referred to as </span><span class="c9">rubber seconds</span><span>.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Rubber seconds</span></p><p class="c4"><span>A second that is slightly longer (or shorter) than the SI unit of a second. This can be used to hide the existence of a leap second.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">JSR-310 time-scale</span></p><p class="c4"><span>A simple time-scale designed to provide the time-of-day to an accuracy suitable for most Java applications. The rules are as follows:</span></p><ol class="c12" start="1"><li class="c4 c21"><span>midday will always be exactly as defined by the agreed international civil time</span></li><li class="c4 c21"><span>other times during the day will be broadly in line with agreed international civil time</span></li><li class="c4 c21"><span>the day will be divided into exactly 86400 subdivisions, referred to as &quot;seconds&quot;</span></li><li class="c4 c21"><span>the Java &quot;second&quot; may differ from an SI second</span></li></ol><p class="c4"><span>The UTC-SLS draft standard is one way to implement the JSR-310 time-scale if the application has access to an accurate underlying clock.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Chronology</span></p><p class="c4"><span>A way of defining time that is meaningful to humans and used in everyday life, also known as a calendar system. It uses individual fields, such as year, month, day, hour minute and second. There are many chronologies, each defining fields in different ways.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Period</span></p><p class="c4"><span>A quantity of time, expressed in terms of the fields of a particular calendar system, such as &quot;five years&quot; or &quot;three hours and twenty minutes.&quot;</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Zone offset</span></p><p class="c4"><span>A period, usually between +14 and -12 hours, that a given location differs from UTC at any given instant. The offset used for a particular location is controlled by government. The value used originally aimed to ensure that the calendar system time of midday (12:00) was equivalent to the solar midday. Today, the offset is influenced by many other factors.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Daylight Saving Time (DST)</span></p><p class="c4"><span>A change to the zone offset that typically occurs each summer. The standard approach is to move clocks forward in the Spring and back in the Autumn/Fall. The two periods are generally known as Summer and Winter time. Whether a given location does this, and on what dates is controlled by local authorities.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Gap and Overlap</span></p><p class="c4"><span>A gap occurs in the local time-line when clocks move forwards, typically in Spring due to DST. An overlap occurs in the local time-line when clocks move back, typically in Autumn/Fall due to DST.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Time zone</span></p><p class="c4"><span>An area of the planet that uses the same zone offset and observes the same rules for changing it due to daylight savings time. A time zone is controlled by government. Some countries have multiple time zones, others share a time zone with their neighbours.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Time zone rules</span></p><p class="c4"><span>A set of rules, for each time zone, that determine how the zone offset varies. A simple set of rules consist solely of a fixed, year round, offset. More complex rules include annual daylight savings changes, historical data and predicted future changes. There are multiple sources of time zone rule data.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Local date/time</span></p><p class="c4"><span>A date or time defined solely using calendar system fields. A local date or time does not represent a fixed instant, or range of instants. For example the local date of 3rd December 2009 will start at one instant in Australia, a later instant in the UK, and an even later instant in the USA. In all cases however, the same local date is referred to.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Offset date/time</span></p><p class="c4"><span>A date or time defined using calendar system fields and a zone offset. Unlike a local date or time, an offset date or time can be converted to and from an instant. For example the local date of 3rd December 2009 refers to a specific instant once the zone offset of 1 hour ahead of UTC is specified.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Zoned date-time</span></p><p class="c4"><span>A date-time defined using calendar system fields, zone offset and time zone. As with an offset date or time, a zoned date-time can be converted to and from an instant. In addition, the presence of a time zone allows accurate calculations of related date-times, such as adding 6 months (which may cause the zone offset to alter).</span></p><p class="c0"><span></span></p><h2 class="c5 c11"><span></span></h2><hr style="page-break-before:always;display:none;"><h2 class="c5 c11"><span></span></h2><h2 class="c5"><span>3. Design Goals</span></h2><p class="c4"><span class="c3">Immutable</span></p><p class="c4"><span>The JSR-310 classes should be immutable wherever possible. Experience over time has shown that APIs at this level should consist of simple immutable objects. These are simple to use, can be easily shared, are inherently thread-safe, friendly to the garbage collector and tend to have fewer bugs due to the limited state-space.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Fluent API</span></p><p class="c4"><span>The API strives to be fluent within the standard patterns of Java SE. A fluent API has methods that are easy to read and understand, specifically when chained together. The key goal here is to simplify the use and enhance the readability of the API.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Clear, explicit and expected</span></p><p class="c4"><span>Each method in the API should be well-defined and clear in what it does. This is not just a question of good Javadoc, but also of ensuring that the method can be called in isolation successfully and meaningfully.</span></p><p class="c0"><span></span></p><p class="c4"><span class="c3">Extensible</span></p><p class="c4"><span>The API should be extensible in well defined ways by application developers, not just JSR authors. The reasoning is simple - there are just far too many weird and wonderful ways to manipulate time. A JSR cannot capture all of them, but an extensible JSR design can allow for them to be added as required by application developers or open source projects.</span></p><p class="c0"><span></span></p><p class="c0"><span></span></p><p class="c5 c16 c8"><span></span></p><h2 class="c5 c11 c7"><span></span></h2><hr style="page-break-before:always;display:none;"><h2 class="c5 c11 c7"><span></span></h2><h2 class="c5 c7"><span>4. Machine and Human</span></h2><p class="c5 c7"><span>We classify dates and times into two basic use cases - machine-scale and human-scale.</span></p><h3 class="c5"><span>4.1 Machine-scale time</span></h3><p class="c4"><span>Machine-scale time represents the passage of time using a single, continually incrementing number. The rules that determine how the scale is measured and communicated are typically defined by international scientific standards organisations.</span></p><p class="c0"><span></span></p><p class="c4"><span>Two key classes are defined to represent machine-scale time:</span></p><p class="c0"><span></span></p><ol class="c12" start="1"><li class="c1"><span class="c3">Instant</span><span>&nbsp;- An instant on the time-line</span></li><li class="c1"><span class="c3">Duration</span><span>&nbsp;- A duration of time</span></li></ol><p class="c0"><span></span></p><p class="c4"><span>These classes use nanosecond precision. The classes have sufficient accuracy to represent any nanosecond instant within the current age of the universe. The epoch used is 1970-01-01T00:00:00Z (midnight at the start of 1 January 1970 UTC), as per the current Java SE date and time classes.</span></p><p class="c0"><span></span></p><h3 class="c15 c18"><span>4.2 Human-scale time</span></h3><p class="c5 c15"><span>Human-scale time represents the passage of time using a number of named </span><span class="c9">fields</span><span>, such as year, month, day, hour, minute and second. The rules that determine how the fields work together are defined in a </span><span class="c9">calendar system</span><span>.</span></p><p class="c5 c15"><span>The design adopted splits the classes into value types and fields/units. Simple applications will not need to be concerned with fields and units.</span></p><h4 class="c5"><span>4.2.1 Value types</span></h4><p class="c4"><span>The high level API contains the following key classes:</span></p><p class="c0"><span></span></p><ol class="c12" start="1"><li class="c1"><span class="c3">LocalDate</span><span>&nbsp;- A date, with no time nor zone-offset</span></li><li class="c1"><span class="c3">LocalTime</span><span>&nbsp;- A time, with no date nor zone-offset</span></li><li class="c1"><span class="c3">LocalDateTime</span><span>&nbsp;- A date-time, with no zone-offset</span></li></ol><ol class="c12" start="1"><li class="c1"><span class="c3">OffsetDate</span><span>&nbsp;- A date and zone-offset, with no time</span></li><li class="c1"><span class="c3">OffsetTime</span><span>&nbsp;- A time and zone-offset, with no date</span></li><li class="c1"><span class="c3">OffsetDateTime</span><span>&nbsp;- A date-time and zone-offset</span></li><li class="c1"><span class="c3">ZonedDateTime</span><span>&nbsp;- A date-time, zone-offset and time-zone</span></li><li class="c1"><span class="c3">ZoneOffset</span><span>&nbsp;- An offset from the time in UTC/GMT</span></li><li class="c1"><span class="c3">ZoneId</span><span>&nbsp;- A time-zone identifier, used to find the underlying rules</span></li><li class="c1"><span class="c3">ISOChronology</span><span>&nbsp;- The standard ISO-8601 calendar system</span></li></ol><p class="c0"><span></span></p><p class="c4"><span>Each of these date-time classes represent time in the ISO calendar system, defined by ISO-8601. This is also known as the proleptic Gregorian calendar system, and is the </span><span class="c9">de facto</span><span>&nbsp;</span><span>civil calendar system used today in the vast majority of the world.</span></p><p class="c0"><span></span></p><p class="c4"><span>Each date-time field can be represented as a value, which is expressed as a </span><span class="c3">long</span><span>. Some fields also have an enum defined for code clarity and safety. These include month, day of week, am/pm and quarter.</span></p><p class="c0"><span></span></p><p class="c4"><span>Although there are lots of classes and each class has lots of methods, the &quot;conceptual weight&quot; of the API is greatly reduced through consistent use of method name prefixes. Some of these prefixes differ from JavaBean conventions because the classes are immutable:</span></p><p class="c0"><span></span></p><ol class="c12" start="1"><li class="c1"><span class="c3">get</span><span>&nbsp;- Gets the specified value</span></li><li class="c1"><span class="c3">with</span><span>&nbsp;- Returns a copy of the object with the specified value changed</span></li><li class="c1"><span class="c3">plus/minus</span><span>&nbsp;- Returns a copy of the object with the specified value added/subtracted</span></li><li class="c1"><span class="c3">multipliedBy/dividedBy/negated</span><span>&nbsp;- Returns a copy of the object with the specified value multiplied/divided/negated</span></li><li class="c1"><span class="c3">to</span><span>&nbsp;- Converts the object to another related type</span></li><li class="c1"><span class="c3">at</span><span>&nbsp;- Returns a new object consisting of this date-time at the specified argument, acting as the builder pattern</span></li><li class="c1"><span class="c3">of</span><span>&nbsp;- Factory methods that don&#39;t involve data conversion</span></li><li class="c1"><span class="c3">from</span><span>&nbsp;- Factory methods that do involve data conversion</span></li></ol><p class="c0"><span></span></p><p class="c5 c15"><span>Applications will also commonly use the </span><span class="c3">DateTimeAdjuster</span><span>&nbsp;interface and the standard implementations provided in </span><span class="c3">DateTimeAdjusters</span><span>. These pre-package common manipulation functions like &ldquo;next Wednesday&rdquo; or the &ldquo;last day of the month&rdquo;. They are especially valuable in capturing the intent of business logic.</span></p><h4 class="c5"><span>4.2.2 Fields and units</span></h4><p class="c5 c7"><span>Dates and times are formed from fields and units.</span></p><p class="c5 c7"><span>A unit is a measurable unit of time, such as a year, month or hour. The set of known units can be extended by applications.</span></p><p class="c5 c7"><span>A field is used to express part of a larger date-time, such as year, month-of-year or second-of-minute. The set of known fields can also be extended by applications.</span></p><p class="c5 c7"><span>Fields and units work together with the abstractions </span><span class="c3">DateTime</span><span>&nbsp;and </span><span class="c3">AdjustableDateTime</span><span>&nbsp;which provide access to date-time classes in a generic manner.</span></p><h4 class="c5"><a name="h.30u7w3fsdpb9"></a><span>4.2.3 Chronologies</span></h4><p class="c4"><span>Other calendar systems are supported with a separate calendar-neutral API. This is focused on the </span><span class="c3">Chronology</span><span>&nbsp;and </span><span class="c3">ChronoDate</span><span>&nbsp;classes. These do not have the same breadth or depth as the main ISO calendar system API.</span></p><p class="c0"><span></span></p><p class="c4"><span>It is recommended that applications use the classes in the main API for all communication between systems and subsystems, including public APIs, storage to a database and communication across the network. The calendar neutral API should be used primarily for user localization.</span></p><p class="c5 c7 c8"><span></span></p><p class="c5 c7 c8"><span></span></p><h3 class="c5"><span>4.3 Machine/Human comparison</span></h3><p class="c5 c7"><span>The division in the API between machine-scale and human-scale is deliberate and necessary, as the two time-scales represent different ways of looking at time.</span></p><p class="c5 c7"><span>The machine-scale approach is very time-line focussed. For example, </span><span class="c3">Instant</span><span>&nbsp;simply represents an instant on the time-line. The only meaningful operations on the class are to check whether the instant is before or after another instant. These classes will be of most use for recording event timestamps and logging.</span></p><p class="c5 c7"><span>The human-scale approach is very focussed on what the time means to a human, through the use of the fields. In addition to getting and setting the field values, methods are provided to perform mathematical operations, such as adding three days to a date. These classes will be of most use in business logic, such as representing the departure time of a train or a customer&#39;s birthday.</span></p><p class="c5 c7 c8"><span></span></p><h3 class="c5"><span>4.4 Calendar/Joda-Time comparison</span></h3><p class="c4"><span>The design adopted is notably different to the Java SE Calendar API and the Joda-Time API.</span></p><p class="c0"><span></span></p><p class="c4"><span>The Java SE Calendar API has a single base class that represents both the date-time and the calendar system. Different calendar systems are implemented as subclasses. This design is flawed as calendar systems are too different to be properly treated as subclasses.</span></p><p class="c0"><span></span></p><p class="c4"><span>The Joda-Time API has simple date-time classes with a plug-in calendar system (chronology). This design, while better than Calendar, is also flawed because each method on the API is unable to properly define its result. For example, the getMonthOfYear() method normally returns a value from 1 to 12, however if the Coptic calendar system has been &quot;plugged in&quot; then the method will return results from 1 to 13.</span></p><p class="c0"><span></span></p><p class="c4"><span>The JSR-310 design ensures that each method on the core API is able to fully define its input and output by focussing the entire class on a single calendar system. The problems of the Java SE API are avoided by not having a common superclass. Instead, users with advanced requirements have to study the API a little more closely and use the low-level calendrical classes.</span></p><p class="c0"><span></span></p><p class="c5 c16 c8"><span></span></p><p class="c5 c8 c16"><span></span></p><h2 class="c5 c11"><span></span></h2><hr style="page-break-before:always;display:none;"><h2 class="c5 c11"><span></span></h2><h2 class="c5"><span>5. Feedback</span></h2><p class="c4"><span>The ThreeTen project and JSR-310 needs feedback! We need reviewers to read the guide and Javadoc, and where possible, try out the code (its still Alpha).</span></p><p class="c0"><span></span></p><p class="c4"><span>Specifically, we need to know if</span></p><ol class="c12" start="1"><li class="c1"><span>the overall shape and size of the API is too large, too small or about right</span></li><li class="c1"><span>whether there are key use cases that are missing (or you can&#39;t find)</span></li><li class="c1"><span>specific method names are too long, too short or unclear</span></li><li class="c1"><span>the API is clear, unclear or about right</span></li><li class="c1"><span>anything else that is an issue</span></li></ol><p class="c0"><span></span></p><p class="c4"><span>Remember - Java SE already has two poor quality date/time APIs. We need to ensure that the third one works well!</span></p><p class="c0"><span></span></p><p class="c4"><span>Feedback can be made by sending an email to, or subscribing to, the </span><span class="c2"><a class="c17" href="">public mailing list</a></span><span>. Emails send to the list during Early Draft Review will be moderated through to the list.</span></p><p class="c0"><span></span></p><p class="c4"><span>Feedback is public information on a trust and respect basis for the public good and may be used by anyone in any way forever.</span></p><p class="c0"><span></span></p><p class="c0"><span></span></p></body></html>
Please sign in to comment.
Something went wrong with that request. Please try again.