Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Remove files now code is at OpenJDK

Avoids confusion as to which project is active
  • Loading branch information...
commit 02c9c7b8c741a9e3f0b67dba13bdefda4dd02c44 1 parent af3b952
@jodastephen jodastephen authored
Showing with 0 additions and 60,492 deletions.
  1. +0 −10 .checkstyle
  2. +0 −16 .classpath
  3. +0 −34 .project
  4. +0 −64 COPYRIGHT-ASSIGN.txt
  5. +0 −31 LICENSE.txt
  6. +0 −203 RELEASE-NOTES.txt
  7. +0 −197 TODO.txt
  8. +0 −22 admin/TestAll.launch
  9. +0 −1  admin/edr2/JSR-310-guide-0.7.html
  10. +0 −135 admin/edr2/Threeten-EDR2.html
  11. +0 −42 admin/legal/authors.txt
  12. +0 −403 admin/survey/AllQ7data.csv
  13. +0 −36 admin/survey/AltResponseQ1data.csv
  14. +0 −36 admin/survey/AltResponseQ2data.csv
  15. +0 −107 admin/survey/AltResponseQ4data.csv
  16. +0 −52 admin/survey/AltResponseQ5data.csv
  17. +0 −37,693 admin/survey/method_names_survey.csv
  18. +0 −41 build.properties
  19. +0 −423 build.xml
  20. +0 −126 checkstyle.xml
  21. +0 −34 maven/jsr-310-TZDB-all.pom
  22. +0 −46 maven/threeten.pom
  23. +0 −155 nbproject/project.xml
  24. +0 −122 src-standard/test/java/javax/time/ClassLoaderTest.java
  25. +0 −128 src-standard/test/java/javax/time/Examples.java
  26. +0 −546 src-standard/test/java/javax/time/Performance.java
  27. +0 −154 src-standard/test/java/javax/time/PerformanceZone.java
  28. +0 −141 src-standard/test/java/javax/time/TestFluentAPI.java
  29. +0 −226 src-standard/test/java/javax/time/UsabilityBasic.java
  30. +0 −205 src-standard/test/java/javax/time/UsabilityChrono.java
  31. +0 −534 src/main/java/javax/time/Clock.java
  32. +0 −69 src/main/java/javax/time/DateTimeException.java
  33. +0 −281 src/main/java/javax/time/DayOfWeek.java
  34. +0 −985 src/main/java/javax/time/Duration.java
  35. +0 −731 src/main/java/javax/time/Instant.java
  36. +0 −1,469 src/main/java/javax/time/LocalDate.java
  37. +0 −1,489 src/main/java/javax/time/LocalDateTime.java
  38. +0 −1,199 src/main/java/javax/time/LocalTime.java
  39. +0 −424 src/main/java/javax/time/Month.java
  40. +0 −569 src/main/java/javax/time/MonthDay.java
  41. +0 −1,059 src/main/java/javax/time/OffsetDate.java
  42. +0 −1,681 src/main/java/javax/time/OffsetDateTime.java
  43. +0 −1,010 src/main/java/javax/time/OffsetTime.java
  44. +0 −1,135 src/main/java/javax/time/Period.java
  45. +0 −275 src/main/java/javax/time/PeriodParser.java
  46. +0 −216 src/main/java/javax/time/Ser.java
  47. +0 −714 src/main/java/javax/time/Year.java
  48. +0 −794 src/main/java/javax/time/YearMonth.java
  49. +0 −438 src/main/java/javax/time/ZoneId.java
  50. +0 −706 src/main/java/javax/time/ZoneOffset.java
  51. +0 −175 src/main/java/javax/time/ZoneRegion.java
  52. +0 −1,760 src/main/java/javax/time/ZonedDateTime.java
  53. +0 −589 src/main/java/javax/time/calendrical/ChronoField.java
  54. +0 −340 src/main/java/javax/time/calendrical/ChronoUnit.java
  55. +0 −421 src/main/java/javax/time/calendrical/DateTime.java
Sorry, we could not display the entire diff because too many files (328) changed.
View
10 .checkstyle
@@ -1,10 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<fileset-config file-format-version="1.2.0" simple-config="true" sync-formatter="false">
- <local-check-config name="ThreeTen" location="checkstyle.xml" type="project" description="">
- <additional-data name="protect-config-file" value="false"/>
- </local-check-config>
- <fileset name="all" enabled="true" check-config-name="ThreeTen" local="true">
- <file-match-pattern match-pattern="." include-pattern="true"/>
- </fileset>
-</fileset-config>
View
16 .classpath
@@ -1,16 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<classpath>
- <classpathentry kind="src" path="src/main/java"/>
- <classpathentry kind="src" path="src/test/java"/>
- <classpathentry kind="src" path="src-standard/test/java"/>
- <classpathentry kind="src" path="src/tck/java"/>
- <classpathentry kind="src" path="src/main/resources"/>
- <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7">
- <accessrules>
- <accessrule kind="accessible" pattern="**"/>
- </accessrules>
- </classpathentry>
- <classpathentry kind="lib" path="lib/test/testng-5.8-jdk15.jar"/>
- <classpathentry exported="true" kind="lib" path="lib/main/jsr-310-TZDB-all.jar"/>
- <classpathentry kind="output" path="bin"/>
-</classpath>
View
34 .project
@@ -1,34 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<projectDescription>
- <name>threeten</name>
- <comment></comment>
- <projects>
- </projects>
- <buildSpec>
- <buildCommand>
- <name>org.eclipse.jdt.core.javabuilder</name>
- <arguments>
- </arguments>
- </buildCommand>
- <buildCommand>
- <name>net.sf.eclipsecs.core.CheckstyleBuilder</name>
- <arguments>
- </arguments>
- </buildCommand>
- </buildSpec>
- <natures>
- <nature>org.eclipse.jdt.core.javanature</nature>
- <nature>net.sf.eclipsecs.core.CheckstyleNature</nature>
- </natures>
- <filteredResources>
- <filter>
- <id>1353369842080</id>
- <name></name>
- <type>26</type>
- <matcher>
- <id>org.eclipse.ui.ide.multiFilter</id>
- <arguments>1.0-name-matches-true-false-.git</arguments>
- </matcher>
- </filter>
- </filteredResources>
-</projectDescription>
View
64 COPYRIGHT-ASSIGN.txt
@@ -1,64 +0,0 @@
-I'm not a lawyer, but I need some framework for accepting contributions to JSR-310.
-Based on cut-and-paste from the Sun Contributor Agreement – version 1.5
-(http://www.sun.com/software/opensource/sca.pdf) here are some terms.
-Basically, I've just changed the title, copyright owner and how to agree.
-
-If you are contributing work to JSR-310, you must agree to these terms (unless a lawyer tells
-me they aren't needed or are invalid...)
-
-
-
-JSR-310 Contributor Agreement
-These terms apply to your contribution of materials to JSR-310, which is a project owned or managed by us ('project'),
-and set out the intellectual property rights you grant to us (Stephen Colebourne & Michael Nascimento Santos)
-in the contributed materials. If this contribution is on behalf of a company, the term 'you' will also mean the
-company you identify below.
-
-To contribute to the project you must agree to these terms. You must confirm your agreement before any
-contribution can be utilized. This could as part of the first patch, or by sending an email to
-the mailing list, currently threeten-develop@lists.sourceforge.net
-
-Read this agreement carefully before signing.
-
-1. The term 'contribution' means any source code, object code, patch, tool, sample, graphic, specification,
-manual, documentation, or any other material posted or submitted by you to a project.
-
-2. With respect to any worldwide copyrights, or copyright applications and registrations, in your contribution:
-• you hereby assign to us joint ownership, and to the extent that such assignment is or becomes invalid,
-ineffective or unenforceable, you hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide,
-no-charge, royalty-free, unrestricted license to exercise all rights under those copyrights. This includes, at
-our option, the right to sublicense these same rights to third parties through multiple levels of sublicensees
-or other licensing arrangements;
-• you agree that each of us can do all things in relation to your contribution as if each of us were the sole
-owners, and if one of us makes a derivative work of your contribution, the one who makes the derivative work
-(or has it made) will be the sole owner of that derivative work;
-• you agree that you will not assert any moral rights in your contribution against us, our licensees or transferees;
-• you agree that we may register a copyright in your contribution and exercise all ownership rights associated
-with it; and
-• you agree that neither of us has any duty to consult with, obtain the consent of, pay or render an accounting
-to the other for any use or distribution of your contribution.
-
-3. With respect to any patents you own, or that you can license without payment to any third party, you hereby
-grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free license to:
-• make, have made, use, sell, offer to sell, import, and otherwise transfer your contribution in whole or in
-part, alone or in combination with or included in any product, work or materials arising out of the project
-to which your contribution was submitted, and
-• at our option, to sublicense these same rights to third parties through multiple levels of sublicensees or
-other licensing arrangements.
-
-4. Except as set out above, you keep all right, title, and interest in your contribution. The rights that you
-grant to us under these terms are effective on the date you first submitted a contribution to us, even if your
-submission took place before the date you sign these terms. Any contribution we make available under any license
-will also be made available under a suitable FSF (Free Software Foundation) or OSI (Open Source Initiative)
-approved license.
-
-5. With respect to your contribution, you represent that:
-• it is an original work and that you can legally grant the rights set out in these terms;
-• it does not to the best of your knowledge violate any third party's copyrights, trademarks, patents, or
-other intellectual property rights; and
-• you are authorized to sign this contract on behalf of your company (if identified below).
-
-6. These terms will be governed by the laws of the State of California and applicable U.S. Federal law. Any
-choice of law rules will not apply.
-
-
View
31 LICENSE.txt
@@ -1,31 +0,0 @@
-/*
- * Copyright (c) 2007-2012, Stephen Colebourne & Michael Nascimento Santos
- *
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *
- * * Redistributions of source code must retain the above copyright notice,
- * this list of conditions and the following disclaimer.
- *
- * * Redistributions in binary form must reproduce the above copyright notice,
- * this list of conditions and the following disclaimer in the documentation
- * and/or other materials provided with the distribution.
- *
- * * Neither the name of JSR-310 nor the names of its contributors
- * may be used to endorse or promote products derived from this software
- * without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
View
203 RELEASE-NOTES.txt
@@ -1,203 +0,0 @@
-/*
- * Copyright (c) 2007-2011, Stephen Colebourne & Michael Nascimento Santos
- *
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *
- * * Redistributions of source code must retain the above copyright notice,
- * this list of conditions and the following disclaimer.
- *
- * * Redistributions in binary form must reproduce the above copyright notice,
- * this list of conditions and the following disclaimer in the documentation
- * and/or other materials provided with the distribution.
- *
- * * Neither the name of JSR-310 nor the names of its contributors
- * may be used to endorse or promote products derived from this software
- * without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-0.7
-===============================================================================
-- Add OffsetDate.toInstant()
-- OffsetDate.isAfter/Before takes into account offset
-- OffsetTime.isAfter/isBefore calculation
-- OffsetTime.compareTo fixed
-- OffsetDateTime.compareTo doesn't handle nanos
-- Add OffsetDate.atTime(OffsetTime)
-- Ensure date-time plus/minus uses long not int
-- Fix Period.of(Duration)
-- Add LocalTime/OffsetTime/LocalDateTime/OffsetDateTime/ZonedDateTime.plus/minus(Duration)
-- Remove CopticDate/HistoricDate.isLeapDay()
-- Add CopticDate.plusWeeks()
-- Change factories on I18N dates to take Calendrical, not DateProvider
-- Rename ZoneOffsetTransition.getDateTime() to getDateTimeBefore()
-- Rename TimeZone to ZoneId (avoids annoying clash with JDK)
-- Fix clock hour of day and of am-pm
-- Fix/Weaken contract of CalendricalRule comparator
-- Change period units to be standalone class for ISO
-- Remove generics from DateTimeFieldRule
-- Rework DateTimeFields, adding DateTimeField
-- Move units and rules from ISOChronology to their own classes as field constants
-- Rename DateTimeFieldRule to DateTimeRule
-- Add A and N formatting letter
-- Change formatting letter x to Y
-- Change formatting letters E and Q to work like M
-- Add narrow style to formatting
-- Add X formatting letter to match current Java, with more power
-- Change formatting letter Z to match current Java, with more power
-- Rename DateTimeParseContext.setParsed to avoid invalid overload
-- Always hold parsed date-time data as DateTimeField
-- Remove DateTimePrinter.isPrintDataAvailable()
-- Change DateTimePrinter to take StringBuilder not Appendable
-- Remove CalendricalPrintFieldException
-- Use ArithmeticException in date classes
-- Add DateTimePrintContext
-- Rename DateTimeFormatterProvider to DateTimeFormatStyleProvider
-- Obtain text from DateTimeTextProvider (remove code from DateTimeRule)
-- Alter/simplify getText() methods in enums
-- Refactor DateTimeFormatSymbols and integrate
-- Add DateTimeRuleRange to replace DateTimeRule min/max methods
-- Add WeekRules
-- Add PeriodUnit.field(long)
-- Add with methods to UTCInstant/TAIInstant
-- Rename ModifiedJulianDays/EpochDays/EpochSeconds/EpochMillis/EpochNanos to remove plural
-- Remove weekend code from main build (currently in extras)
-- Add ofInstantUTC factories to ZDT, ODT, OD, OT
-- Remove Comparable, PeriodUnit, PeriodRange, ID and Chronology from CalendricalRule
-- Remove isXxx() methods from enums
-- Rename CalendricalRule.getReifiedType() to getType()
-- Combine ZoneId.getName() and getShortName() into getText()
-- Rename WeekOfMonth to AlignedWeekOfMonth, similarly for WeekOfYear
-- Remove getChronology() in most places, Use get(Chronology.rule()) instead
-- Rewrite merging
-- Factories from Calendrical varargs
-- LocalDate constants for MIN_DATE/MAX_DATE (using Year.MIN_VALUE Jan 1/MAX_VALUE Dec 31)
-- LocalTime constants for MIN_TIME/MAX_TIME (using MIN = MIDNIGHT, and MAX = 23:59:59.999999999)
-- LocalDateTime constants for MIN_DATE_TIME/MAX_DATE_TIME (combining min and max from LocalDate/LocalTime)
-- Year.parse(String), Year.parse(String,DateTimeFormatter) and toString(DateTimeFormatter)
-- SystemUTCRules now load leap second data from binary JAR entry
-- TZDBZoneRulesCompiler now also compiles leap second information from TZDB files
-- Parse methods use CharSequence
-- Remove DateProvider, TimeProvider, DateTimeProvider, as they created unreliable APIs
-- Refactor PeriodUnit
-- Rename getEstimatedDuration() to getDurationEstimate()
-- ZoneResolver refactored
-- Remove LocalTime.Overflow, embedding code in LocalDateTime
-- Rename DateTimeFormatter methods for clarity
-- Move TimeDefinition to rule class from builder
-- Remove DateAdjuster/TimeAdjuster from Offset* classes and clarify with methods
-- Add parseBest to handle optional parsing
-- Moved packages
-- Merged Clock and TimeSource
-- Removed UTC/TAI
-
-0.6.3
-===============================================================================
-- nanoOfDay rule / epochDays rule
-- Use public factories for ZOT and ZOTR rather than protected methods in ZRules
-- Make CalendricalRule.compare less lenient
-- Add TAIInstant.parse()
-- Print/parse two digit years
-- Add Period.toEstimatedDuration()
-- Rename PeriodFields.normalize() to normalizeTo()
-- Add PeriodFields.normalize()
-- Add Period.of(Duration)
-- Make LocalDate.plus(PeriodProvider)/minus(PeriodProvider) strict
-- Remove DatePeriod, adding methods to Period
-- Add Period.withDateFieldsOnly()/withTimeFieldsOnly()
-- Add Period.ofDateFields()/ofTimeFields()
-- Rename Period.ofYearsMonthsDays() to ofDateFields()
-- Rename Period.ofHoursMinutesSeconds() to ofTimeFields()
-- LocalDateTime/LocalTime/Year/YearMonth.plus(PeriodProvider) have correct algorithm
-- ZoneOffset period factory
-- ZDT int factories
-- YearMonth.with(Year)
-- LocalTime plus/minus shouldn't throw ArithmeticException
-- Remove InstantProvider from UTC/TAI
-- OffsetTime.withOffset/adjustLocalTime method names changed
-- Add isLeapYear() to other principal date classes
-- Fix bug in Offset* now(Clock)
-- Rename nowSystemClock() to now()
-- MonthOfYear - start/end of month as DOY
-- Add Chronology CalendricalRule
-- Change ISO year range to -999,999,999 to 999,999,999
-- Add OffsetDateTime.of(DateProvider,OffsetTime)
-- Add LocalDate.atTime(OffsetTime)
-- Remove toYear() from principal classes
-
-0.6.2
-===============================================================================
-- PeriodFields.toTotal(Unit)
-- PeriodFields.normalize(Unit...)
-- Rename/add methods on PeriodUnit
-- Add Year/YearMonth/MonthDay.now(Clock)
-- Add LocalDate.isLeapYear()
-- Rework time-scales
- - less public classes
- - simplified UTC should always have 86400 seconds per day
- - TAI and UTC
- - pluggable leap seconds
-- ZoneRulesGroup loads rules, whereas it should just load keys initially
- - Specialised data format for zone-rules
- - SPI and zone providers
-- TimeZone special factory to create unavailable instances
-
-0.61
-===============================================================================
-- getYearMonth(), getMonthDay()
-- withXxx() taking Year, MonthOfYear - with(Adjuster)
-- zone prev/next transition
-- parse API is too complex to parse Date/Time due to merge
-- Date/Time parse factories
-- DateTimeMatcher -> CalendricalMatcher
-- test separable comparators for providers -> CalendricalRule implements Comparator
-- isJanuary() ?
-- isMonday() ?
-- Period rules?
-- period units in chronologies?
-- Year.of() Duration.of() plus big static class?
-- parse optional needs to store and drop back Calendrical properly
-- withDayOfYear() tests and everywhere
-- toDays() etc, if we keep those classes
-- Year.atDay()
-- LocalDate.atTime(int...)
-- review in line with changes to Duration
-- ZonedDateTime plusDurationSeconds() etc
-- public access to transitions and transition rules
-- OffsetInfo, discontinuity rename to transition
-- parse zone
-
-EDR
-===============================================================================
-- OffsetDate.atTime(int...)
-- zone rule where time of day is 24:00
-- versions of zone data files
-- convert time zone rules to fixed rules when possible
-- simpler way to setup pattern - DateTimeFormatters.forPattern()
-- Factory now(Clock)
-- optimise Clock methods to Local* avoiding Offset* object creation
-- better error when zone jar file missing
-- setup list of deprecated time zone ids
-- ZonedDateTime toEpochSeconds()
-- OffsetDateTime.fromEpochSeconds()
-- ZonedDateTime.fromEpochSeconds()
-- Duration/Instant rename millis() to ofMillis() etc
-- Duration/Instant integrate TimeUnit
-- Rename factory methods to start with 'of'
-- LocalDate.plus(PeriodProvider) needs correct algorithm
-- Period.ofXxx factory rename
-
View
197 TODO.txt
@@ -1,197 +0,0 @@
-/*
- * Copyright (c) 2007-2012, Stephen Colebourne & Michael Nascimento Santos
- *
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- *
- * * Redistributions of source code must retain the above copyright notice,
- * this list of conditions and the following disclaimer.
- *
- * * Redistributions in binary form must reproduce the above copyright notice,
- * this list of conditions and the following disclaimer in the documentation
- * and/or other materials provided with the distribution.
- *
- * * Neither the name of JSR-310 nor the names of its contributors
- * may be used to endorse or promote products derived from this software
- * without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
- * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
- * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-Simple tasks
-------------
-- Test min/max year for week-based-year. The max/min year is 999,999,999.
- But the week-based-year may be 1,000,000,000. This needs testing.
- The info will vary according to the WeekRules chosen, so will need to be a method on WeekRules.
-
-
-More complex tasks
-------------------
-Utils
-- MathUtils can't be public, can't put in java.math as we require JDK5 support
-
-Duration
-
-Instant
-- improve toString/parse
-- implement Calendrical?
-
-Time scales (UTC/TAI)
-
-Date/Time classes
-- DateResolver rework - takes int or MonthOfDay or calendricals
-- OffsetDateTime.toEpochSecs() could be private
-- with(Calendrical) - need to figure out how
-- remove ISO chronology from LocalDate etc classes
-- try to remove DateTimeRuleGroup
-- DateTimeFields.roll
-? InstantProvider implementations toEpochMillis()
-? getMonthOfYear() -> getMonth(), etc
-? Calendrical rule for date/time as a period (for between calculations)
-? MonthOfYear methods taking year, as well as boolean
-
-Rules
-- DateTimeField.from(Cal...)
-- Change DAY_OF_MONTH.field(6) to DAY_OF_MONTH.of(6) - to act like factories, also period units
-- ensure other calendar systems re-use ISO defined rules
-- Handle case where values have gaps, eg 1,2, 4,5,6, 8
-? parse()
-? deriveInt for fields
-? ISO era
-? Remove WEEK_BASED_YEAR and WEEK_OF_ -> WeekRules
-
-Date/Time formatting
-- merger - general processing
-- merger - days overflow
-- merge ISO weekyear
-- parse 24:00 - maybe a special end-of-day class?
-- SPI for date-time text
-- strict/lenient parse
-? upper/lower case
-- Arabic numbers have negative sign after number
-- parseInto(Calendrical)
-- default calendrical to pre-define era for example
-- check compatible with RFC "Wed, 02 Apr 2008" and j.u.Date "Wed Apr 02 time zone 2008"
-? substitute text (replacing built in text for Months/DOW etc)
-
-Time zones
-- Use WET/CET/EET as valid short abbreviations?
-- SPI for zone names
-- parse/format names
-# some zones have transitions where only the name changes - America/Resolute
-- aliases resolved at runtime not compile time
-- test against TZDB binary data
-? get region ids by offset (JDK method)
-? Drop Etc (signs reversed), Older country based IDs
-# (EST, MST, HST changed in 2005r - no longer observe DST - http://java.sun.com/developer/technicalArticles/Intl/alertFurtherInfo.html)
-# (MET no longer Asia/Tehran, now Middle Europe)
-# http://java.sun.com/javase/tzupdater_README.html
-# http://java.sun.com/javase/timezones/tzdata_versions.html
-# http://java.sun.com/javase/timezones/DST_faq.html
-# http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5055567 and related
-# JDK TimeZone.setDefault sets an inherited thread local
-# Platform specific ids - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6534626
-# Change zone info dynamically - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4701860
-# Exception on bad zone - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4412864
-
-Periods
-- WIP branch, decide on normalization
-- Between factories -> ? DAYS.between(date1, date2) - difference between epoch amounts in unit
-- Formatting/parsing (defer?)
-- Period.toString is not output of state
-
-Matchers/Adjusters
-- more general next/previous
-? recurrences
-
-Calendars
-- HistoricChronology
-- EthiopicChronology
-- more calendar systems
-- Coptic year definition
-- plus/minus long vs int
-
-JDK integration
-- Proper integration into OpenJDK classes for providers
-- Proper CLDR provider implementations
-
-General
-- Split Clock so only system implementation is in core?
-- remove ArithmeticException from javadoc -> spec/overview
-- cache todays date
-- localized day of week number -> WeekRules
-- get month/weekday text
-- serialization formats
-- evaluate hash codes
-- check overflows
-? factories/methods taking double - double is very unreliable
-
-===============================================================================
-Possible items
-- roll()
-- round() - truncateToSeconds() feels weird
-- iteration
-- era in the hash codes
-- ModJulDays rule - BigDecimal
-- IntValue interface, implemented by Number/Integer
-- public factory for LocalDate.fromDayOfYear(year, doy)
-- Optimise LocalDateTime plus/minus times by having a local plus(int,int,int,long,sign,LocalDate) method
-- intervals (defer completely?)
-- HalfDays period unit for AM/PM (more accurate than 12 hours)
-- InvalidDateException - better exception name?
-- simplify Clock to Calendrical, merging
-
-Use cases
-- Day of Olympiad (roughly four year period)
-
-===============================================================================
-Done
-
-Document
-- requirement: non JDK extensible
-- null approach - nulls rejected except in isXxx() and in framework-level code
-- type-safe where sensible
-- many-headed problem
--- Zone - Local/Offset/Zoned
--- Precision - Y/YM/YMD/HM/HMS/HMSN/DateTime/...
--- Calendar - ISO/Julian/Coptic/...
--- FieldTypes - Y/M/D/H/M/S...
--- Periods - Y/M/D/H/M/S...
-- Joda issues
--- Instant vs Partial
--- Partial with time zone
--- Not easily extensible
--- Chronology is complex
--- Date holding chronology is complex
--- Exposed long millis
-- Parsing with wrong pattern letter case (month vs minute, doy vs dom) is caught
-- Obtain leap-second rules from TZDB rather than a file
-
-Not doing
-- Use nanoOfDay rule in LocalTime factory - NO, as doesn't work
-- toString(pattern)/parse(str, pattern) - NO, due to ease of formatter usage
-- Add getAmPm() to time classes - NO, due to low use case
-- Remove TimeSource replace by InstantProvider - NO, due to UTC/TAI
-- don't use Local Mean Time - add a flag to the TZDB compiler to determine whether it uses
- LMT or not. LMT is the estimated time before time-zones were introduced. The JDK removes LMT times,
- and we should have a flag to do the same. Need to check exact way in which JDK removes LMT!
- - NO, see email thread - unclear as to whether change is beneficial
-- get rule by name - NO some rules are based on data
-- get chrono by name - NO some rules are based on data
-- Rename DateProvider to LocalDateProvider - NO, interface was removed
-- Rename period classes - NO, current names seem fine
-- Promote TimeDefinition to top-level type - NO, moved it to rule class instead
-- date.with(RULE, value) / date.plus(amount, UNIT) - NO, because date.plus(UNIT.of(amount)) works well enough
-- DateTimeAdjuster - NO, it adds more complexity
View
22 admin/TestAll.launch
@@ -1,22 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<launchConfiguration type="org.testng.eclipse.launchconfig">
-<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="org.testng.remote.RemoteTestNG"/>
-<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="threeten"/>
-<mapAttribute key="org.testng.eclipse.ALL_CLASS_METHODS"/>
-<listAttribute key="org.testng.eclipse.CLASS_TEST_LIST"/>
-<listAttribute key="org.testng.eclipse.GROUP_LIST"/>
-<listAttribute key="org.testng.eclipse.GROUP_LIST_CLASS"/>
-<stringAttribute key="org.testng.eclipse.LOG_LEVEL" value="2"/>
-<listAttribute key="org.testng.eclipse.METHOD_TEST_LIST"/>
-<listAttribute key="org.testng.eclipse.PACKAGE_TEST_LIST">
-<listEntry value="javax.time"/>
-<listEntry value="javax.time.calendrical"/>
-<listEntry value="javax.time.chrono"/>
-<listEntry value="javax.time.chrono.global"/>
-<listEntry value="javax.time.format"/>
-<listEntry value="javax.time.zone"/>
-</listAttribute>
-<mapAttribute key="org.testng.eclipse.PARAMETERS"/>
-<stringAttribute key="org.testng.eclipse.PREDEFINED_LISTENERS" value=""/>
-<intAttribute key="org.testng.eclipse.TYPE" value="5"/>
-</launchConfiguration>
View
1  admin/edr2/JSR-310-guide-0.7.html
@@ -1 +0,0 @@
-<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="http://threeten.sourceforge.net">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="http://www.cl.cam.ac.uk/%7Emgk25/time/utc-sls/draft-kuhn-leapsecond-00.txt">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="https://sourceforge.net/mail/?group_id=386712">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>
View
135 admin/edr2/Threeten-EDR2.html
@@ -1,135 +0,0 @@
-<html>
-<body>
-<h3>Document in support for Early Draft Review (2) for JSR-310</h3>
-<p>
-This document supports the second EDR for JSR-310, a JSR now intended to form part of JDK-8.
-See the <a href="http://jcp.org/en/resources/guide7">guide for submission</a>.
-</p>
-
-<h4>Question 1 - Evaluation license</h4>
-<p>
-The specification will be provided in zipped Javadoc form, together with an accompanying guide (not part of the specification).
-</p>
-<p>
-The license for EDR should be the same as the first EDR, which is the standard evaluation license.
-The Javadoc will also be freely available through other means.
-</p>
-
-<h4>Question 2 - Duration</h4>
-<p>
-The EDR should last 30 days.
-</p>
-
-<h4>Question 3 - Content</h4>
-<p>
-For the Javadoc specification the following applies:<br />
-A. Does the specification include software codes in the following format:<br />
- Binary : No <br />
- Source (compilable) : No <br />
- Javadocs : Yes <br />
-B. Do the codes or the spec call on, contain, use or demonstrate encryption technology?<br />
- Encryption: No <br />
-</p>
-<p>
-For the non-specification accompanying guide:<br />
-A. Does the specification include software codes in the following format:<br />
- Binary : No <br />
- Source (compilable) : No <br />
- Javadocs : No <br />
-B. Do the codes or the spec call on, contain, use or demonstrate encryption technology?<br />
- Encryption: No <br />
-</p>
-
-<h4>Question 4 - Transparency</h4>
-<p>
-This sections fulfils the <a href="http://jcp.org/en/resources/transparency">transparency requirements</a> for version 2.7 of the process.
-</p>
-<ul>
-<li><p>
-<b>The public can read the names of the people on the Expert Group (ie, not just JCP Members)?</b>
-</p><p>
-The names of Expert Group members are listed on the JCP website, however some are listed only by company.
-In practice, this question is moot, as the active group of experts is simply those participating in
-the <a href="https://sourceforge.net/mail/?group_id=386712">primary mailing list</a>.
-</p>
-<li><p>
-<b>The Expert Group business is regularly reported on a publicly readable alias? </b>
-</p><p>
-All business is conducted on the mailing list, with information about face-to-face meetings being forwarded.
-</p>
-<li><p>
-<b>The schedule for the JSR is publicly available, it's current, and I update it regularly?</b>
-</p><p>
-JSR-310 will be included in Java<sup><font size="1">TM</font></sup> 8 Release (JSR-337).
-The schedule is Java<sup><font size="1">TM</font></sup> 8 release schedule starting with the JavaTM SE 8 release Public Review.
-</p>
-<li><p>
-<b>The public can read/write to a wiki for my JSR? </b>
-</p><p>
- A public <a href="https://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen">readable wiki</a>
- for the JSR exists. It is not publicly writable, discussion is encouraged at the mailing list instead.
-</p>
-<li><p>
-<b>I have a discussion board for my JSR and I regularly read and respond to posts on that board? </b>
-</p><p>
-All discussion occurs on the <a href="https://sourceforge.net/mail/?group_id=386712">primary mailing list</a>.
-Spec leads regularly participate on the list.
-</p>
-<li><p>
-<b>There is an issue-tracker for my JSR that the public can read? </b>
-</p><p>
-The <a href="https://github.com/ThreeTen/threeten/issues">primary issue tracker</a>, now located at GitHub, is fully read-write.
-</p>
-<li><p>
-<b>I have spoken at conferences and events about my JSR recently? </b>
-</p><p>
-The JSR has been discussed at conferences numerous times over time.
-</p>
-<li><p>
-<b>I am using open-source processes for the development of the RI and/or TCK? </b>
-</p><p>
-The JSR has been run along Open Source lines since the beginning.
-The source code of the Reference Implementation and TCK has driven the specification.
-The source code has always been available, first at <a href="https://sourceforge.net/projects/threeten/">Sourceforge</a>
-and now at <a href="https://github.com/ThreeTen/threeten">GitHub</a>.
-The project has evolved guided by a public mailing list.
-</p>
-<li><p>
-<b>The Community tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR? </b>
- The community tab has the key link to the project <a href="http://sourceforge.net/apps/mediawiki/threeten/">home page</a>.
- The links in the transparency section are out of date.
-</p>
-</ul>
-<p>
-The following question from the v2.8 transparency checklist is also answered:
-</p>
-<ul>
-<li><p>
-<b>What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA? </b>
-</p><p>
-The source code is available under the <a href="https://github.com/ThreeTen/threeten/blob/master/LICENSE.txt">BSD 3-clause license</a>.
-Discussion contributions are freely accepted, however code contributions are accepted under the
-<a href="https://github.com/ThreeTen/threeten/blob/master/COPYRIGHT-ASSIGN.txt">JSR-310 Contributor Agreement</a>, based on the previous Sun Contributor Agreement.
-</p>
-</ul>
-
-<h4>Question 5 - License terms</h4>
-<p>
-The Final Specification, Final RI, and Final Technology Compatibility Kit will be the Java<sup><font size="1">TM</font></sup> 8 Release.
-</p>
-<p>
-A separate forked project may continue the work of JSR-310 for earlier JDKs, however such a project would not be a JSR implementation.
-</p>
-
-<h4>Question 6 - Version number and Spec leads</h4>
-<p>
-The specification is version 0.7.
-</p>
-<p>
-The release date is dependent on the Java<sup><font size="1">TM</font></sup> 8 Release.
-</p>
-<p>
-The spec leads are Stephen Colebourne, Michael Nascimento Santos and Roger Riggs (Oracle Inc.)
-</p>
-</body>
-</html>
View
42 admin/legal/authors.txt
@@ -1,42 +0,0 @@
-
-git shortlog -sne --no-merges --all
-
-authors as of 2012-07-06:
-Master:
- 1739 Stephen Colebourne <scolebourne@joda.org>
- 150 Michael Nascimento Santos <misterm@gmail.com>
- 41 Richard Warburton <richardw@insightfullogic.com>
- 36 Richard Warburton <richard.warburton@gmail.com>
- 21 Jim Gough <jpgough@gmail.com>
- 13 Jesper Steen M°ller <jesper@selskabet.org>
- 11 Mark Thornton <mthornton@optrak.co.uk>
- 9 Roger Riggs <roger.riggs@oracle.com>
- 8 Fabio Kung <fabio.kung@gmail.com>
- 7 Darryl West <dpw@raincitysoftware.com>
- 5 barend <bgarvelink@xebia.com>
- 4 renjith4 <renjith4@gmail.com>
- 3 Benjamin Graf <benjamin.graf@gmx.net>
- 3 sjmisterm <misterm@gmail.com>
- 2 Faisal <cfaisalm@gmail.com>
- 1 Ryoji Suzuki <ryoji.suzuki@oracle.com>
- 1 Viktor Hedefalk <hedefalk@gmail.com>
-
-All branches:
- 1868 Stephen Colebourne <scolebourne@joda.org>
- 150 Michael Nascimento Santos <misterm@gmail.com>
- 43 Mark Thornton <mthornton@optrak.co.uk>
- 41 Richard Warburton <richardw@insightfullogic.com>
- 36 Richard Warburton <richard.warburton@gmail.com>
- 21 Jim Gough <jpgough@gmail.com>
- 18 Roger Riggs <roger.riggs@oracle.com>
- 13 Jesper Steen M°ller <jesper@selskabet.org>
- 8 Fabio Kung <fabio.kung@gmail.com>
- 7 Darryl West <dpw@raincitysoftware.com>
- 5 barend <bgarvelink@xebia.com>
- 4 renjith4 <renjith4@gmail.com>
- 3 Benjamin Graf <benjamin.graf@gmx.net>
- 3 sjmisterm <misterm@gmail.com>
- 2 Faisal <cfaisalm@gmail.com>
- 1 Ryoji Suzuki <ryoji.suzuki@oracle.com>
- 1 Viktor Hedefalk <hedefalk@gmail.com>
-
View
403 admin/survey/AllQ7data.csv
@@ -1,403 +0,0 @@
-Response
-"Nanosecond is a whole word, there is no such thing as ""Nano"", and ""Nano of a second"". It's nanosecond."
-"""if I saw getDay() I would assume ""... nothing and check the JavaDoc until I learned"
-"Natural use has priority to simplest naming i.e. When you give time, its HH:MM:SS,mmm, those three numbers must be available under getHour, getMinute, getSecond, getNano(|Second)...
-Secondary uses get secondary names i.e. getDayOfWeek (by the way, it may return a Day enum).
-Enum holds both a litteral (string) name and an ordinal (may it goes from 1 to 12 ?)
-
-Thanks for asking !"
-"leverage JodaTime conventions if possible - it will help that many people won't have to re-learn
-
-I am split on 5). I'd likely go w/ option 1 if I had no other choice"
-getDay is never correct as there are multiple possible meanings. getHour is correct as there is only one possible meaning. If all other getXXX return an int then getMonth must return an int.
-"Names should be as long as necessary to convey the idea and no longer. Shorter names should be reserved for the common cases (e.g. getDay() for get day of month) and use longer names for the less used cases (e.g. getDayOfYear()).
-
-Do not abbreviate words e.g. getNanosecond() vs. getNano()--with IDE code completion it's not a big deal for writing but it is a big deal for reading."
-"Method name length should be increased only when unclear. There should be no need for MonthOfYear, because that's the only way month is represented (MonthOfX is only valid where X == Year; compared to DayOfX, where X is a set {Year, Month, Week})"
-"There are thousands of Java developers who don't have English as their main language, consider avoiding cultural assumptions (i.e. some people think day-month-year, while others year-month-day)"
-"q4) (assume 'now' is current time of day)
-now.getNanoOfSecond - wrong 'now' is not in seconds its a timeofday
-now.getNano - good if nano's from midnight wrong if in seconds (maybe as given in other options)"
-Avoid get before method names
-Method names don't need to be too explicit as everything in Java has context. There's nothing wrong with getDay() as long as it is used within the context of a larger time period. e.g. if we are talking about weeks then I expect getDay() to get the day of the week whereas if we are talking about months I would expect it to be day of the month. Don't be one of those people that puts the letters impl at the end of their class names. That's implied.......
-"I find all the ""Of year"", ""Of month"", etc naming conventions unnecessary. There is a reasonable expectation that getDay will return 1-31."
-"Considering the modern IDE can show all possible methods, the associated javadoc and auto complete the method name (eg ctrl+space in eclipse) I would keep the model as simple as possible to represents date and time, but the utilities methods (e.g. Date conversion UTC to GMT) very clear and with a consistent name convention."
-"Essentially if I see 20120609 I think year, month, day. Americans will think month, day, year when they see 06092012 and Europeans will think day, month, year.
-Hence those are the obvious names for year, monthOfYear and dayOfMonth. The extra information is assumed and anything else will be confusing or tedious.
-Basically this pattern trumps the need for consistency.
-
-There is never a good reason to read Javadoc. My IDE is set to automatically hide all comments."
-Consider auto-complete and dynamic help provided by development enviornments - I do not use text pad anymore!
-"enums for months are contraproductive with respect to other calendars.
-Names (for months or days or eras) are locale dependent."
-"Stuff like getMonthOfYear / getHourOfDay is definitely too much.
-
-Differentiating on day-of-* may be useful. On the other hand the major use case of getting the day is day-of-month, so I would use getDay for that one."
-"Quick to write, and length of method is irrelevant in an era of code completing IDEs. Readability is the only concern."
-"We shouldnt go for verbosity for verbosities sake but everything should be unambiguous in its context and as much as possible consistent in the general API.
- people familiar with Calendar ints will still heav flash backs and nightmare bugs if you return ints and not enums in places where there is a chance for index by 1 or 0."
-"On getMonthOfYear() : which other type of getMonthOfXXX would you have? It seems pointless - you would not want month of decade?
-
-However, getDay() is ambiguous - getDay for the week? Month? Year?"
-It should be self explanatory
-"If auto-complete on 'getD' showed getDay(), getDayOfWeek() and getDayOfYear(), it'd be obvious enough that getDay() returned the day of the month.
-
-getDayOfMonth() seems a bit verbose, but isn't much worse."
-"assuming date and time classes are immutable, theres little point in prefixing them with get as there is no corresponding set (eg date.month()).
-
-using methods that return boolean for queries on enums are usually clear and provide better encapsulation, eg, date.isIn(MARCH) vs date.month() == MARCH"
-Keep the most common cases short (single word).
-no
-"Avoid unnecessary ambiguity, for instance getTime()"
-Methods should not surprise or have side effects.
-Prefer not too many similarly named methods on one class as leads to confusion and reduced IDE autocomplete effecacy
-The abstraction reprenting by the method name must talk to real human (not only programmer)
-Deviating from what java.util.Date and/or java.util.Calendar have used is going to cause confusion. I think it best to use their naming as a model in spite of the shortcomings in the rest of the API.
-"I would hazard that the vast majority of Java developers use an IDE with auto-complete, so typing and length-of-name issues are almost non-existent. And when reading from a popup list of method names, it should be clear what the method is going to do. So, preferably, as long as necessary to be unambiguous, but no longer.
-
-Ambiguity is present in days – Is it the day of month, day of week, or day of year? – so a longer, unambiguous name is better (e.g. getDayOfWeek()). That problem is not inherent in the relationship between hours/minutes/seconds/nanos – few people care about the nth hour of the month – so there is no need to lengthen the names."
-"Actually, make em as in .NET, easy to read, understand and use."
-Need thread safe class to increment time / date.
-"MonthOfYear? are there other concepts of Month? on the other hand, it's a good differentiator from getMonth(), and plays even better with getMonth -> Enum (get a REAL Month), getMonthOfYear -> int (get me the nth month). By the way, will January be 0 or 1? There will be blood on that one, either way."
-"I prefer that the methods that I use the most have the shorter names, as long as they're clear. If you want there to be a method that returns an enum, I think I'd prefer aDate.getMonth() to return an int, and aDate.getMonthEnum() to return the enum, because I'll rarely use the enum version but would like the difference to be clear."
-Hope that the API supports these ideas across different Chronologies and not just the Gregorian chronology.
-"don't repeat yourself, think object, concept :
-If the class represent an entity ""date"", no need to precise that day is the day of the month and not of the week ! That's clear.
-The more concise (and clear of course) is the best.
-If you have a lot of methods in the class ....then you need to read the javadoc to understand the subtile differences."
-No
-Nope
-focus on the most common use cases and use verbose methods for more special things like dayOfYear or dayOfWeek
-Hard choice. good luck.
-"Short names should not drive the naming choice, answer to that can be auto completion. Over-explicit names should be avoided too, when I read getMonthOfYear I simply wonder getMonthOfWhatElse ? Ambiguity is also a thing try to avoid, it makes people assume the expected behavior, and sometime we assume wrong :)"
-"I favor unambiguous, consistent naming. I prefer terse APIs, but not to the point where terseness leads to ambiguity.
-
-The question I'm most uncertain about is #5 (month-of-year enum vs int), as I can see common use cases for both int and the enum value. However, I think returning the enum and having the enum contain the ordinal value is cleaner than the other suggestions."
-"javabean style get prefix is an unnecessarily noisy convention.
-
-overloading the API for ordinals rather than simply accessing them via secondary access is unnecessary. Prefer:
-
-int month = date.month().ordinal();"
-"One potential naming convention is that the shortest names should be in reference to the next bigger increment of size. For example getDay() could be days of a week. However, we don't communicate dates using all the units going from biggest to smallest. For example, we could write our dates like this:
-Year Month WeekOfMonth DayOfWeek (as in 2012 May 2 Wednesday)
-This is confusing though, because we don't know which day of the week we start the month on. So there's a good reason the default is 2012 May 9. For the same reason, I think getDay() should return the day of the month."
-"Discoverability: If I see a getYear(), I *assume* there's also a getDay(). I'd never guess a getDayOfMonth(), so I think the day/month/year combination (as used in the ""real world"") has better discoverability."
-"Is day DayOfWeek an enum? If not, it should."
-"support for financial years? attribution of week to year during overlaps? week to month?
-ok, not related to method naming but these use cases explain why getMonthOfYear is a good idea because there may be many cases - getMonthOfFinancialYear, getYearOfWeek etc"
-"The shorter forms suggested are the default ways those components are discussed in normal language in the context of the object. Given the date X what is the month, not Month of Year. Longer forms should be reserved for the less natural meanings."
-"Choosing a name that satisfies all of a bunch of mutually contradictory goals is a real trick in API design. Doesn't make the goals any less important. That's why they're almost all a 1.
-
-Modern IDEs serve up javadoc very conveniently. The need to read it should not be seen as a problem with the API."
-no
-"1. Avoid verbose disambiguation when the meaning is obvious e.g. getHour() over getHourOfDay()
-2. Avoid ambiguity e.g. getDay() : of what.. week, month year?
-3. Are there calendar / chronology systems that don't work with the familiar year, month, day, hour, minute, second terms - that need special naming handling?"
-"Consistency above all else. You can't please everyone, but you can please no one. Good luck."
-"People use these in everyday life, and use certain terms with expected meanings. That should drive the design. The general conventions for 'common' use are year, month (January, February, etc), day (which is 99.9% for day of month), hour, minutes, seconds. You should use verbose forms for the uncommon uses, such as day of year, month number, month abbrev, etc."
-"Why do you need to say getMonthOfYear -- what other month is there? GetMonthOfDecade?
-For Day, it makes sense to differentiate between day of month vs day of year."
-Methods should be clear. It doesn't matter if they are too long or too verbose.
-"""Balance of short and clear"" is the most important point here, I believe. Clarity should take priority though. So, first of all, method name has to be clear and only then - as short as possible (without losing clarity)."
-"getYear, getMonth, getHour, getSecond, etc., need no further explanation because their scope is unambiguous. Day (unfortunately!) has two scopes and so can benefit from the additional clarity.
-
-Enum for month because there is ambiguity between zero-indexed months and one-indexed months. None of the other values have such an ambiguity."
-"We have code completion, thus length or number of characters is not an issue at all, right?"
-no
-"Unambiguous methods, like getMonth(), should not have suffixes, like OfYear, as there is no other OfSomething.
-Ambigous methods like getDay() should not exist at all, it should always be getDayOfMonth(), getDayOfYear(), getDayOfWeek().
-So IMHO only unambiguous names should be short, other should be longer to remove the ambiguity."
-Take good parts from JODA time APi
-"There are 2 forms of unambiguous:
-- Ambiguous with other methods in the same API. This is very bad (agree level 1).
-- Ambiguous as to what are it's side effects. This is less bad (agree level 3). It's often impossible and impractical to name all side effects in the method name. That's why we have javadocs."
-Read time over write time. Zelf documenting
-succinct but definitely not cryptic
-"#6 table really wants a ""Concise"" option, such I suspect that ""balance of short and clear"" covers that."
-"MonthOfYear and DayOfYear etc etc must NOT be zero-based. December must IMNSHO be number 12 (not 11 thank you!). This must be kept consistent with HourOfDay, MinuteOfHour and the way people generally think about ordered things.
-An enum for e.g. Month is a good idea since it can contain the number of the month (1-12) as well as the number of days in the month (0-31) (yes, leap year is a problem there).
-Best of luck! ///Anders"
-"I think you can rely on other method names to disambiguate a method, since code completion tools usually show a list of methods. If I don't know a class, but I see it has both getDay() and getDayOfWeek() methods, I will assume the getDay() method means day of month."
-"Not naming really, but please - months should be numbered 1-12, not 0-11!"
-"The JDK Date and Calendar namings is a disaster, ambiguous and assuming too much thing silently. IDE now provide completion which make method naming length a lower issue than 15 years ago.
-
-Thank you for your work on Joda Time, this library is a real pleasure to use.
-Regards,"
-"When you see a method, it should be clear what the method is doing/returning. So make methodnames meaningfull instead of to short."
-Drop the enums. Make getZeroBasedXX methods that return zero based month and day of week. Do not overengineer. A good API is an API that is straightforward to the user and doesn't surprise. Complexity is bad.
-"With code completion in ides long method names become less of an aggravation.
-Unless we are forced to use notepad or vi clarity and consistency should always take precedence over method name shortness."
-"It's date and time, everybody will use it often. Now it's cumbersome and requires reading either way - long method names don't matter so much and most often the usage is for mainstream cases - where getDay should get day of month, not year nor week."
-Concise & Consistent rules.
-"For immutable objects, such as time related objects, it might be useful to consider the following option:
-
-time.minute, time.second, time.nano
-
-If the hosting class file is immutable, the fields inside may be public final fields, thus allowing their use is very concise way. Getters could exist for POJO and bean use."
-I prefer property based retrievers over getters. monthOfYear() over getMonthOfYear.
-The more intuitive the better
-"It's considered a good practice that method names describe somehow its parameters.
-
-I'd like to propose the following syntax for methods:
-
-example 1)
-
-traditional way:
-
-add(2,3);
-
-add(int a, int b) { ..}
-
-
-
-proposed:
-
-add(2)plus(3);
-
-add(int a)plus(int b) { .. }
-
-
-
-
-
-example 2)
-
-traditional way:
-
-perform(tiles, request, response, context);
-
-perform(ComponentContext tilesContext,
- HttpServletRequest request,
- HttpServletResponse response,
- ServletContext servletContext) {... }
-
-
-
-proposed:
-
-performWithTiles(tiles)theRequest(request)returning(response)inContext(context);
-
-
-performWithTiles(ComponentContext tilesContext)theRequest(HttpServletRequest request)returning
-(HttpServletResponse response)inContext(ServletContext servletContext) { ... }
-
-
-
-example 3)
-
-traditional way:
-
-getItemFromFile(file,item);
-
-getItemFromFile(File file,String item) { .. }
-
-
-
-
-proposed:
-
-getItem(item)FromFile(file);
-
-getItem(String itemfromFile(File file) { .. }"
-"In the case of the date methods, I think it shoud be short but clear. Date methods are functions you will be use mostly everyday."
-"Naming should be shortest possible, but not like getDoY(), It's more important that it's absolutely clear what the method does."
-"I think now an API should be designed considering the fact, that most of the developers use IDEs in 90% of their time. IDEs are smart. They show you the Javadoc (""No need to read Javadoc""), complete the parameters, etc..."
-Make it idiot proof
-"These are all valid goals and well in general this also depends much on context ... API or not? internal or external? tests or product?
-
-Sometimes I prefer conciseness, sometimes verbosity - of course not all at the same time ;-) ..."
-"'Clear when read' to means concise, among other things. You have to know what your doing when using dates anyway, as with any other API, so having to read up on the specifics of the various functions is not a problem in my view. It would be great if names like getYear, getMonth and getDay were so short because you coul tell in an instant what was going on. It's DWIM to me."
-"For question 8: I'd like to use Joda-Time, but only if it was in JDK. All other libraries use Date so I don't want to wrap/unwrap it again and again."
-I'm sending and e-mail to Stephen Colebourne with my suggestions.
-method naming choice might be influenced by social and linguistic norms. This might be problematic given the variance of said norms from region to region.
-"KISS (Keep it Short & Simple)
-- In common language, when talking about dates we simply use ""month"" (for month of year), ""day"" (for day of month), etc.
-- Avoid mixing zero-based integer (e.g. month) and integer starting from 1 (e.g. day). Both should start from 1."
-nobody writes javacode outside an ide now which does autocomplete and javadoc. It is not necessary to worry about the length of method names (other than writing code that reads like a bad novel!).
-Names should be the shortest they can be while providing as little ambiguity (primary concern) as possible.
-"Please January = 1 !!!!
-Please nice builders to create date/time/datetime."
-"The current method naming convention in threeten is perfect and one of the things I like most about the library. In fact, prior to using it, I was writing a small date library for GWT and came up with an eerily similar naming convention independently.
-
-One thing I'd possibly like to see changed (slightly OT) is ZonedDateTime.now(). I think it would be beneficial to enforce the user to always pass the ZoneId. ZonedDateTime.now(ZoneId)
-
-Although it would no longer be consistent with Instant.now(), I think this is actually a good thing."
-"Most of the times I want the day within a month. That's why I think that getDay() should return the day of month and instead of getDayOfMonth, have a method named getDayOfWeek() which, to me, is much less used plus, it has 1 character less to write :-)"
-None
-"Not on method naming so much as organization: put all these things in its own package. java.util.Month is not as clear as java.util.date.Month. We all agree dealing with dates is big, it deserves its own package, if only to help make the API a whole lot clearer and unambiguous."
-dontGiveMeAnAPIThatHasSuchLongNamesThatItTakesAWeekendToRetrieveTheDateAndTime
-"Joda time is a good model to follow. There are some inconsistencies with it, but its what I've been using for years."
-"Short is better. This class will be used a lot. getDay() should be fairly obvious, especially when the other option is getDayOfYear() clearly indicates what is happening. Also, January should be 1, not 0."
-"Too bad you have to have the Java Bean ""get"" prefix."
-"Avoid redundancy: getMinuteOfHour() provides no more context of getMinute()... though possible to consider number of minutes in the context of a day, say, it is far from the common case. Adhering to a pattern here would be silly."
-"Please keep the access to data as simple as possible e.g.
-Bad int month = getMonth().getValue();
-Good int month = getMonth();
-
-What about overloading a getMonth(), getYear() and getDay() to return the 'name' if the return type is a string, the numeric value if the return type is int etc. IMO it would make very consistent coding without adding all the boilerplate of the original date implementation."
-"I suggest following the Microsoft conventions for DateTime. They were faced with the same questions and came up with a sensible solution. On top of that, by following their convention, you make it easier on the many developers who straddle both languages.
-
-By the way, some of these issues wouldn't be so bad if Java had implicit conversion like Scala. Then your API could simple be getYear(), getMonth(), getDay() all returning int. Instead of so many methods, you'd have implicit conversions to convert everything. Except dayOfWeek, but you could still have an implicit conversion from LocalDate to DayOfWeek, as many of the Joda/Scala wrappers do."
-"Balance clarity and brevity. These classes will be used so frequently that competent Java developers will become accustomed to any shortcomings in immediate meaning, e.g. the behavior of getDay()."
-prefer single words that can be used as a DSL
-"I think in most APIs context is King. Ambiguity in method naming becomes a bit easier when the context of the object is in play. For instance, if I write something like newDateObj.getSecond() its not clear, but if I write newDateObject.getDayOfMonth().getHour().getMinute().getSecond() suddenly the string of fluent calls lends a context that tells me the parameters of getSecond(), namely that it will be between 0 and 59. This allows slightly shorter and more concise naming. However, it does introduce some lengthy code calls as evidenced in my example. For any core API I think the overriding concept should be KISS."
-Verbose unambiguous names is a high-cost for the bogus goal of an API that doesn't need docs
-"Should be able to guess the intent with out reading the API. And consistent across date, time, and, other temporal classes in java.util and java.sql also."
-Current time in millis since epoch is already available but what about current seconds since epoch used by other systems/languages?
-"Don't forget date creation.
-It is a pain to create date without Joda-Time."
-Very important: Consistent!! + Balance of short and clear
-"In the case that the method is not too long to describe the whole text, the worst case is that you have to review the javadoc one time to understand and learn."
-.
-"Long and clear is WAY better than short and dubious.
-We all have HUGE screens now with huge resolution, we all have IDEs with auto-complete, we all have huge memories and we don't need to limit to 8 characters or less when naming things."
-None. The above list is quite exhaustive.
-Avoid naming anything as a description of their implementation as much as possible. Example: AbstractSingletonProxyFactoryBean is an atrocious name that means nothing to someone who's trying figure to figure out what to use it for. As far as a philosophical reason: It breaks encapsulation.
-"it would be an advantage to also be able to do simple day/time based calculations with a functional style API (i.e. thinking about BigDecimal add(), substract()... methods)"
-"it doesn't really matters if they are long, as long as they are clear."
-"I think that brevity when possible, and longer names when necessary is a good balance; consistency should be relaxed if necessary (it's nice to have but not the only or most imporant goal).
-Javadocs can still be inspected in case of doubt: different people have different intuitions.
-I used to believe more in long-if-need-be to maximize consistency, minimize ambiguity -- I have learnt over time, with experience that smart people do not need to be nannied that way, and it's better to ""use common sense"" -- only few would be confused by 'getDay()' choice of day-of-month I think, or offended by lack of consistency (wrt getDayOfWeek/-Year)."
-"Shorter is better, leaning to more verbose when there are multiple options that deviate from the default."
-No
-Keep it simple !
-"Read code with ""Joda Time"", even with Ruby (time.rb) and C#. In order to got a pleasure API.
-
-I agree wit getting a powerful API, not one that keep me guessing ""what's going on?"".
-String API in Java is actually poor in methods. I think another epic fail. Keep it simple, but maybe you guys are able to introuduce something like ""Collections"" Class. ""Date & Time"" mus be the power utility that other languages envy."
-"Develop the API thinking that most of programers think in a date and time with some format like '2012/05/10' or '11:10:10 AM', it should guide the names for clases and methods."
-I'v always appreciated when method call chains can be read almost lika a sentence eg. Mockito
-Why don't You use JodaTime?
-Please include joda time
-"You are probably approaching this problem too, but the java.util.Date method called getTime() has probably the worse name ever."
-"Are we talking POSIX or normal (English localisation?) month int?
-
-Dates are primarily split as year-month (of year)-day (of month). Week is kind of an orthogonal issue, and day of year (or month of decade or whatever) is secondary for non-specialist purposes."
-Perhaps getDayOfWeek() could be getWeekDay()? Also it is not completely clear whether that method returns the day's number (ie. 0 for sunday/monday) or the name of the day (ie. monday)
-"In my eyes the only misinterpretable method is 'getDay().
-
-But here my IDE tells me, that there exist 'getDayOfWeek()' and 'getDayOfYear()' as well, so that I then know that 'getDay()' in fact is day of month => Keep it short."
-"getDay() requires verbosity because Day can be represented several ways - day of the week, day of the month, day of the year. getMonthOfYear() is wrong (IMHO) because month only has one basic representation - month in a year."
-"The terms I use when describing dates are: Year, Month, Day, Day of Week. I never actually refer to the Day of Year, so no comment.
-The terms I use when describing time are: Hour, Minutes, Seconds, Nanoseconds. I've never heard the term ""nano of second"" — is this a copy-paste mistake?"
-Nope.
-don't break time zones
-thanks for your effort! I hope Java will have a clean data API at last!
-"Dates are tipically represented as a day, a month and a year. We all asume day represents day of month and month represents month of year. So I chose de less verbose and the clearer form.
-
-I'd also like to say sth about having an enum for month: since we can have no emun for year and day, it's weird (and ugly) using an int for them and an enum for months. Besides, we don't need an enum to make clearer the use of months: month 3 is not an odd code that we have to translate, everybody knows that month 3 is march (first month is 1, not 0, of course :) ). And being able to iterate over the enum is not reason enough to make mor complex the API."
-Use Joda Time FFS and disregard all input I gave you.
-Love to feel you are hearing us! :)
-"This naming is only part of the problem. A much bigger issue are the (IMHO) flawed concepts and overall design. JSR-310 is better than Joda and java.util anything, but it is still lacking in accuracy and layering.
-
-There are effectively only a handful of concepts at a ""scientifical"" level, which should form the basis; PointInTime, TimePeriod (from-to) and Periodicity (recurring), which then can be combined in many ways for more complex concepts (meeting every Monday at 12:30-13:00 until Sept 12 this year). But the REPRESENTATION is different thing, and right now it feels like there is a poor separation of those.
-
-I have mentioned my concerns to Colebourne, but he disagrees and make a strong argument for the blur that I think still exists."
-"Looks like good thought has gone into it. JodaTime is good, but not 100% perfect. I really enjoy doing Time and Date operations in Ruby. Maybe my preference for conciseness over Verbose comes from that (or too many Calendar.getInstance() calls !)"
-"for everyone, ""day"" IS the ""day of month"", no need to specify more"
-"ad question 5: I am aware the first option leads to clean and narrow API surface, however the getMonthInt would be practical"
-January should be 1 not 0
-"Not explaining the issue of getMonth returning an enum, while others return ints, naively favored the simpler api. On retrospect, it becomes a harder choice and I'd favor consistency by returning an int. However, millis and nanos being longs would be a break, but a minor one. So I'd favor getMonthOfYear being the enum as the special case and/or have Month accept an int valueOf factory method."
-No
-"Why do not have a method return how many days of one month in this year ,Like Year(2012).Month(January).days() = 31;"
-"ad 5) may ""enum getMonth()"" return null? If so, then getMonthInt() is nice, otherwise it's not necessary."
-"getters and setters are an antipattern to many, it's too bad so many frameworks rely on it. Without taking those into consideration, a method like dateVariable.month() is better to me than dateVariable.getMonth()."
-"This will be a heavily used API - programmers will learn moderate ambiguity. Focus on pattern usage - the more frequently used method, the shorter name it should have."
-"The first things comes in mind when you read the method name. If it relates with the result, we should name in that way. e.g getMinute() means obviously minute of the hour. Hence getMinuteOfHour does look right here."
-I think consistency and clarity of the API is the most important.
-It must be clear to understand however it must not be too long. The developer must understand what it is for before looking at java doc or making a simple example of it.
-Clarity when reading code is the most important.
-"Just clarify that for me Agree = 5 is the greatest. See ""Clear when read"" for instance..
-Anyway there are only 4 radio buttons when the numbers are from 1 to 5.."
-".NET's DateTime is way better that Java's Calendar or whatever (native), just copy the API and be happy. Also include a TimeSpan object"
-"Month implies month-of-year, so getMonth() would be sufficient."
-"Call data nouns, actions verbs. Keep the names simple and the names that match how you would verbally explain things to other people. The language already has a simple pattern ""verbNoun"", so hold to that consistently whenever possible (so that anyone's guess is most likely correct). Type out coding examples without looking at what you have done, and if what you typed doesn't match what you have, fix what you have (most of the time). Don't get overly pedantic."
-Additional to q5 : Year and DayOfWeek should be more than an int.
-"There is no need to prepend ""get"" to all methods. These aren't beans."
-"enum for month literal, please!!!"
-"You read your source many more times that you write it, so the more verbose the method names are the better. Especially for people who will be doing future work with your source base will thank you. The simpler the source code is the better."
-"Re getDay() the API should not rely on assumptions or on people reading the javadoc.
-Re methods on time w/o date - they are unambiguous without the extra fluff. What would the minute be if not minute of hour? If there is also going to be a minute of day method then the extra fluff is required to disambiguated."
-toString() formatted understandably
-"The most important for me would be ""clear when read"" and ""Unambiguous"" followed by ""balance of short and clear"" when possible"
-"All API method names should be clear and unambiguous, whilst trying to striking a balance between conciseness. Some slightly verbose methods is fine when it helps to avoid ambiguity.
-
-The getDay/getDayOfYear/getDayOfWeek methods being a good example of ambiguity. For getDay(), it could take you a while to work out what this meant ""get the day of the what? is it the day of the week or month"". Only when you use javadoc do you see the other day methods, getDayOfWeek/getDayOfYear do you realise that it implicitly means dayOfMonth (as the most common use case). However, once you've written the code, so if someone new comes to review the code, or you yourself come back to the same code a few weeks/months later, you'll be asking the same ""get day of the what?"" question again.
-
-When there is no ambiguity then use concise method, getMonth/getYear/getHour/getMinute/getSecond/getNano."
---
-"When I see a date and/or time, I read: year, month, day, hour, minute, second.
-Each unit is a portion of the previous unit, that is, there is an expected and understood containership.
-If there is a deviation from this pattern, that deviation must be made clear. For example; getDay() would be a value from 0 or 1 to 27 or 31 (depending on month and origin), getDayOfYear() would be a value from 0 or 1 to 364 or 366 (like Julian date), getDayOfWeek() would be an enum (Sunday to Saturday).
-A method name like getMonthOfYear, implies that there is a meaning of month that is not part of a year. Given that method name, I would expect other methods for month such as getMonthOfxxx. If this is in fact the case, that months can be a part of something other than a year, then the methods names should be qualified with an Ofxxx suffix.
-Additionally, if I saw a method like getMonthOfYear, I would also expect to see a method getYearOfxxx (where xxx might be Gregorian or Mayan etc). I am sure that this is not what is intended by this new date/time class."
-"All APIs should be as easy to use as possible, as the latest generations of programmers barely read anything."
-Just use Joda Time as the new API :)
-Similar to Joda Time
-Be similar to JodaTime.
-N/A
-no
-"simply, method define clear,no various."
-soon
-Shortest possible
-The first month must be int 1
-Follow human's common sense and convention.
-"brief & unambiguous, it's important"
-i hope the java source code will be write more comments
-"I don't know if it is the case for any country/language/culture but IMHO day, month, hour, minute, ... are always clear and will be read as ""dayOfMonth"", ""monthOfYear"", ""hourOfDay"", ..."
-With the method name .. it would be sufficient to read the java doc once and then i think it should be clear that getDay returns the day of the month ..
-"Not on naming convention, but a question on the Month Enum, how many methods can it have? A Month has multiple display values (APR, April) and will the Enum have all these values exposed as methods? If these standard operations are not made available, should the Enum be created at all?"
-It should be as close to YodaTime naming as it is possible.
-"No, have fun deciding."
-"length to type is not important - IDEs have auto complete
-
-is there is a possibility of confision then it will occur. Be explicit and non ambiguous"
-"No need short names - auto completion is there.
-Need to be clear because code is read more than written,
-Also being specific in methods naming yields less conflicts
-with later adds."
-"Alternative for the time-of-day class:
-getHour(), getMinute(), getSecond(), getNanoSecond()
-
-Maybe additionally some of:
-int getMilli(Second)() // as fraction of a second
-int getMicro(Second)() // as fraction of a second
-
-int getSecondOfHour() // as fraction of an hour
-int getSecondOfDay() // as fraction of a day
-int getSecondOfYear() // as fraction of a year
-int getSecondFromZero() // absolute from year 0
-
-int getMilliOfMinute() // as fraction of a minute
-int getMilliOfHour() // as fraction of an hour
-int getMilliOfDay() // as fraction of a day
-long getMilliOfYear() // as fraction of a year
-long getMilliFromZero() // absolute from year 0
-
-int getMicroOfMinute() // as fraction of a minute
-long getMicroOfHour() // as fraction of an hour
-long getMicroOfDay() // as fraction of a day
-long getMicroOfYear() // as fraction of a year
-long getMicroFromZero() // absolute from year 0
-
-long getNanoOfMinute() // as fraction of a minute
-long getNanoOfHour() // as fraction of an hour
-long getNanoOfDay() // as fraction of a day
-long getNanoOfYear() // as fraction of a year"
-take care about i18n.
-"natural decomposition is a factor in method naming, and determines the neaning of the simple names.
-
-The natural decomposition of date, is year/month/day so day of year and day of week are secondary and those should have the longer names.
-
-The natural decomposition of time is hour/minute/second/subsecondOfSomeresolution"
-Since all major IDE support code assistence/suggestion (e.g. Ctrl-Space in Eclipse) there's no need to think about the shortest possible method names.
-"Should correspond to terms used in daily life, e.g normally when we ask which day it is, it is usually day of them month"
-"Short method names like getMonth, getDay, getMinute are sufficient because they correspond to how we normally use them in speach and thus don't need additional clarification (though on first use you might want to check the docs just to verify that they're consistent with folk usage of the terms)."
-"In your get Day example, week never occurred to me, but day of year vs day of month did.... names must be explicit. Hours of confusion for seconds of savings in typing is not a good trade. If you didn't want to type, you should have picked another profession :) That said, when clarity can be achieved in fewer words it helps with line-length, and thus brevity also helps readability, just not as much as clear method names.
-
-The Month vs MonthOfYear class name question is a mystery to me. Why would this be an issue? Are months ever subject to anything else besides years? What would we confuse it with? Seasons?
-
-Will we have to input a gps lat/long so that growing zones or a global GIS ecosystems layer are used to calcuate the season? I can just see it now... Season.SPRING, Season.SUMMER, Season.FALL, Season.WINTER... wait, where do we put Season.DRY? (Joke!) :) Please tell me you aren't planning on having MonthOfEpoch! :)"
-"while I would normally interpret getDay() as day of week, in the context of a class encapsulating a date, I would interpret it as day of the month"
-No
-Consider plurals e.g. getSeconds() for numeric results.
View
36 admin/survey/AltResponseQ1data.csv
@@ -1,36 +0,0 @@
-A month number 1-12. Enum value doesn't take into account regional differences.
-"Per #5, nuke the enum"
-Months.APRIL (The enum is a container of Months)
-"no enum -- String monthName( int, locale )"
-MM
-Month.BLAH where Month implements some interface to allow other enums for different month strategies
-Months.APRIL
-CalendarMonth.APRIL
-GregorianMonth
-CalendarMonth.APRIL
-MonthName
-Months
-MonthName
-MonthNames
-"No enums. Seriously, stop overengineering. Everyone knows first month (1) is January, etc."
-MonthName
-"Month.APRIL, GregorianMonth.APRIL, MonthOfGregorianYear.APRIL"
-Months
-GregorianCalendarMonth
-use an int. Enums are inappropriate for this use case.
-Month.Apr
-GregorianCalendar.Month.APRIL
-GregorianMonths
-"no month of year, just starting with January"
-"Not needed, the number is self-explicative"
-MonthName
-GregorianMonth? There are other terms for months in non-english calendars. For e.g. my local calendar http://en.wikipedia.org/wiki/Tamil_calendar#Months.
-"Not to have an enum. The code dealing with dates is mostly generic - ""new Date(1776, Month.July, 4)"" would be seen in examples only. No need for enum then."
-MM.APRIL
-Months.APRIL
-Year.APRIL
-Keep it as a number
-APRIL
-NameOfMonth
-"Don't use enum, Months.getName(int x), Months.getName(int x, Locale locale)"
-MonthEnum
View
36 admin/survey/AltResponseQ2data.csv
@@ -1,36 +0,0 @@
-"Make Date immutable, have year, month, day etc. as public final fields"
-"getYY(),getMM(),getDD(),getDD_YY(),getDD_W()"
-"date.year(), date.isOnA(Monday),etc..."
-now.getDayOfWeek()
-"year(), month(), day(), dayOfYear(), dayOfWeek() get prefix is unnecessary noise"
-"year(), month() etc merged with the third option"
-"getYear(), getMonth(), getDay(), getDayOfYear(), getDayOfWeek(), getWeekOfYear"
-"getYear(), getMonth(), getDay()"
-"getYear(), getMonth(), getDay()"
-getDate()
-"getYear(), getMonth(), getDay(), getOfYear(), getOfWeek()"
-"getYear(), getMonth(), getDay(), getMonthOfYear(), getDayOfYear(), getDayOfWeek()"
-"getYear(), getMonth(), getMonthName(), getDay(), getDayOfYear(), getDayName()"
-"getYear(), getMonth(), getDay(), getWeekday()"
-"getYear(), getMonthOfYear(), getDayOfMonth(), getDayOfYear(), getDayOfWeek(), getQuarterOfyear(), getQuarterStartDate(), getQuarterEndDate()"
-"same as option 2, eventually add internal Enum for a single getDay(DayOf): getDay(DayOf.MONTH/YEAR/WEEK)"
-unsure
-last option and getWeekOfYear
-"getYear(), getMonth(), getMonthName(), getDay(), getDayName(), getDayOfYear()"
-"getDay() to get the day of the given date, and getDayOfMonth to get the day within the given month. Also, similar methods with the today prefix, for working with the current date."
-"year(), month(), day(), dayofYear(), dayOfWeek()"
-"getYear(), getMonth(), getDay()"
-getToday()
-You know better than me :) if in doubt use joda-time names
-perhaps getDayOf(DateUnit) ?
-"getYear(), getMonth(), getDayM() or getMonthDay(), getDayY() or getYearDay(), getDayW() or getWeekDay()"
-"getYear(), getMonth(), getDayOfMonth(), getDayOfYear(), getDayOfWeek(), getWeekOfYear()"
-"getYear(), getMonth(), getDay(), getDayOfYear(), getDayOfWeek(), getWeekOfYear()"
-getLastDayOfMonth()
-"getYear(), getMonth(), getDay(), getDayOfMonth(), getDayOfYear(), getDayOfWeek()"
-"year(),month(),dayOfMonth(),dayOfYear(),dayOfweek()"
-"getYear(), getMonth(), getDay(MONTH), getDay(YEAR), getDay(WEEK)"
-year();month();day();week()
-"year(), month(), day(), dayOfYear(), dayOfWeek() - set methods would share name, but would have argument (e.g. java.nio.Buffer.{limit(), position()} and similar in java.nio.*, java.lang.ProcessBuilder.{command(), directory(), etc.},"
-"getYearNoonUTC() etc. The world is inconveniently round, but a time is absolutely meaningless without a timezone. Don't support the flawed notion that it time has meaning without location. This will lead to phenominal amounts of buggy code since most business folks (i.e. project sponsors) don't get timezones and will try to tell programers not to worry about timezones. Force the programmers to understand the issue so that they can respond with appropriate and logical arguments. The existence of such a class would be a detriment to Java's reputation in the long run. Noon UTC will behave well everywhere but perhaps midway etc. When it does misbehave it will be clear why it did so. Do not foster the notion that timezone can be ignored."
-"getYear(), getMonth(), getDay(), getDayOfYear(), getWeek()"
View
107 admin/survey/AltResponseQ4data.csv
@@ -1,107 +0,0 @@
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSeconds()"
-"getHour(), getMinute(), getSecond(), getNanosecond() -- Everything else is spelled out"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"Make Time immutable, have hour, minute, second and nano as public final fields"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"last, but with ""Nanosecond"" (it's a word!)"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-the same as the last option but can we also have getMinutes getSeconds getNanos or asMinutes asSeconds asNanos so that we can get the aggregate minute of the day instead of minute unit... or you could call it HourUnit MinuteUnit SecondUnit and GetMinutes GetSeconds it should be clear... and it should provide more functionality.
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHourOfFay(), getMinute(), getSecond(), getNanoOfSecond()"
-"time.hour(), time.minute(),etc..."
-"getHour(), getMinute(), getSecond(), getMilli(), getNano()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond() or plurals of those"
-"getHour(), getMinute(), getSecond(), getMilliseconds()()"
-"getHour(), getMinute(), getSecond(), getMinuteOfDay(), getSecondOfDay(), getMillisecondOfDay(), getMillisecondOfSecond(), getNanosecondOfDay(), getNanosecondOfSecond()"
-"getHour(), getMinutes(), getSeconds(), getNanos()"
-"getHour(), getMinute(), getSecond(), getMillisecond(), getNanosecond()"
-"hour(), minute(), second(), nano()"
-"getHour, getMinute, getSecond, getNanoSecond"
-This class is not a good idea and will cause confusion.
-"getHour(), getMinute(), getSecond(), getNanosec("
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getMillis(), getNano()"
-"the first (getHOD, getMOH, getSOM, getNOS) plus an extra getMinutesOfDay and getSecondsOfDay"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour, getMinute, getSecond, getMilli, getMicro, getNano"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getMiliSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-getHourComponent() possibly.. suggesting that each part of the time is a time-component
-"getHour(), getMinute(), getSecond(), getMilliSecond(), getNanoSecond()"
-"getHour, getMinute, getSecond, getMillisecond"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-".hour(), .minute(), .second(), .nano()"
-"getHour(), getMinute(), getSecond(), getNanosecond()()"
-"getHour, getMinute, getSecond, getNanosecond"
-There should be two methods for getting hours in 24 and in 12 hour format. There should also be a method to get am and pm.
-"getHour(), getMinute(), getSecond(), getNanoSeconds()"
-getHour() getMinutes() getSeconds() getNanos()
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHours(), getMinutes(), getSeconds(), getNanos()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(),getMilliSecond(),getNano()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-getNanoSecond()
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHours(), getMinutes(), getSeconds(), getNanoSeconds()"
-"getHour(), getMinute(), getSecond(), getMillisecond (), getNanosecond()"
-"timeOfDay.getH(), getM(), getS(), getN()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getMinute() to get the minutes of the given time, and getMinutesHour to get the minute within the given hour. Also, similar methods with the today prefix, for working with the current time."
-"hour(), minute(), second(), nano()"
-"getHour(), getMinute(), getSecond(), getMilliSeconds(), getNanoSeconds()"
-"getHour(), getMinute(), getSecond(), getMillisecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-getNow()
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-You know better
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinutes(), getSeconds(), getNanoseconds()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSeconds()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-LocalTime from joda-time
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), ..., getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getMillisecond(), getNanosecond(), getNanoOfSecond()"
-"hourOfDay(), minuteOfHour(), secondOfMinute(), nanoOfSecond()"
-hour();min();secs();nano()
-"getHour(),getMinute(),getSecond(),getNanoSecond()"
-"hour(), minute(), second(), nano() same comment as Q2"
-"getHour(), getMinute(), getSecond(), getNanoSecond()"
-"getHour(), getMinute(), getSecond(), getNanosecond()"
-"getHour(), getMinute(), getSecond(), getMillis(), getNano()"
-"The third one, but getMillis() as well. Don't make us do our own math to play with the older versions of java. This does not suffer from the timezone issue of #2 because the units are (mostly) the same size or smaller than the timezone increment, and they are not meaningless as they relate approximately to the position of the sun in the sky.."
View
52 admin/survey/AltResponseQ5data.csv
@@ -1,52 +0,0 @@
-"getMonthOrdinal() delegates to enum.ordinal, and getMonth() returns the enum"
-"getMonthValue() returns an int; getMonth() returns an enum, with the int value available via a method on the enum"
-seperate getMonth() and getMonthEnum() methods
-"getMonthOfYear() returns enum, getMonthOfYearValue() returns int"
-getMonth() returns an int; getMonthValue() returns an enum
-"Return int, enums are meaningless if the set is not fixed. For example, which month in the Jewish calendar does FEBRUARY map to?"
-getMonth() returns an int; getMonthEnum() returns an enum
-No preference
-int-value on the Enum
-"I wouldnt use ints, gives impression you can do math with them, assuming you have methods for adding/substracting dates - otherwise option 1"
-getMonth()returns an enum; getMonthAsInt() returns an int
-getMonthNumber() => int; getMonth => enum
-"provide the int value, but a lookup to the enum member"
-"getMonth() returns an enum, enum has a getter for the int representation"
-enum's ordinal() value simply is the int. Or the enum has a getter for the int.
-getMonth() returnd an int; getLongMonth() returns an enum
-1 or 6
-getMonthNumber() returns an int; getMonthOfYear returns an enum
-getMonth() returns an enum; getMonth().intValue() returns an int
-getMonth() returns an int; getMonthName() returns an enum
-int can be zero-indexed or 1-indexed. So I don't like the idea that it's represented by an int at all
-getMonthInt() and getMonthEnum()
-"getMonthOfYear() => int, getMonthOfYearEnum() -> enum"
-"getMonth() should return int, getMonthAsEnum() should return an enum."
-"getMonth() returns an int, getMonthName() returns an enum"
-both returning int
-"getMonth() returns an int, but there should be enum for Gregorian calendar months which should have static method that takes an int and returns the corresponding enum."
-unsure
-"As in #2 another idea, getXxx() returns the int, getXxxName() returns the enum"
-getMont() returns as int; getMonthOfYear() returns as int
-getMonthAsEnum()
-getMonth() returns as int; getMonthAsEnum() returns an enum
-getMonth() returns an int; getMontAsEnum() returns an enum
-"Would use enum, but I'd have to look at the API if this is to impractical (for toString() and arithmetic). The enum would be even better if more functionality would be put in there. More type info is also nice to have."
-"only have a method returning the enum, with the int value available via a method on the enum, and that method returning the same value as ordinal()"
-getMonth() returns an int; use enum to translate int to enum
-getMonth() returns an int; getMontValue() returns an enum
-"getMonthNum() for the int,"
-getMonth returns an int; Month.valueOf(date.getMonth()) - that's how to create month enum
-getMonth() returns enum and int representation of month is enum's ordinal.
-getMonth() returns an int; getMonthEnum() returns an enum
-getMonth() returns an int; getMonthEnum() returns an enum
-getMonth() returns an int; getMonths() returns an enum
-"getMonth() returns an enum,"
-getMonth() returns an enum where the value is an int
-getMonth() returns an int; Month.get(int) returns an enum
-I would like it be int. It will be nice to get number_of_days diff from two Date objects.
-getMonthInt() returns an int; getMonthEnum() returns an enum
-not sure
-"First alternative: ""returning enum, with int value available via the enum"" as this will make more obvious that JANUARY is 1 (and not 0)"
-getMonth() returns an int; getMonthEnum() returns an enum
-getMonth() returns an int; getMonthEnum() returns an enum
View
37,693 admin/survey/method_names_survey.csv
0 additions, 37,693 deletions not shown
View
41 build.properties
@@ -1,41 +0,0 @@
-version.full = 0.7.0-alpha
-
-build = build
-build.main = build/main
-build.test = build/test
-build.javadoc = build/javadoc
-build.coverage = build/coverage
-
-src = src
-core.main = src/main/java
-core.main.resources = src/main/resources
-core.test = src/test/java
-core.tck = src/tck/java
-core.main.classes = ${build.main}/core
-core.test.classes = ${build.test}/core
-
-# -- sources for se module classes
-standard.test = src-standard/test/java
-standard.test.classes = ${build.test}/standard
-
-# -- source for the TZDB
-tzdata.main = src/main/tzdata
-tzdata.main.workarea = ${build.main}/tzdb
-tzdb.files = africa antarctica asia australasia backward etcetera europe northamerica southamerica
-tzdb.outputjar = jsr-310-TZDB-all.jar
-
-lib.test = lib/test
-lib.main = lib/main
-lib.optional = lib/optional
-lib.coverage = lib/coverage
-
-# -- source for sigtest/tck
-sigtest.loc = ${lib.test}/sigtestdev.jar
-sigtest.dist.file = sigtest-2-2.zip
-sigtest.dist.jarloc = sigtest-2.2/lib/sigtestdev.jar
-sigtest.dist.origin = http://download.java.net/sigtest/2.2/Rel/sigtest-2_2-MR-bin-b17-21_mar_2011.zip
-
-dist = dist
-dist.workarea = dist/work
-
-maven.repo.url = http://repo1.maven.org/maven2
View
423 build.xml
@@ -1,423 +0,0 @@
-<!--
- Ant Build for ThreeTen
-
- @author Fabio Kung (fabio.kung@gmail.com)
- @author Michael Nascimento Santos
- @author Oliver Fischer (o.b.fischer@swe-blog.net)
- @author Stephen Colebourne
- @author Richard Warburton
- @author Benjamin Graf
--->
-<project name="threeten" default="dist">
- <description>
- ThreeTen date and time API, reference implementation for JSR 310
- </description>
-
- <property file="build.properties" />
- <property file="version.properties"/>
- <tstamp />
-
- <property name="maven" value="${dist}/maven" />
-
- <property name="jarBase" value="threeten-${version.full}" />
- <property name="jarName" value="${jarBase}.jar" />
- <property name="jarNameSources" value="${jarBase}-sources.jar" />
- <property name="jarNameJavadoc" value="${jarBase}-javadoc.jar" />
- <property name="jarNamePom" value="${jarBase}.pom" />
- <property name="jarCoreName" value="threeten-core-${version.full}.jar" />
- <property name="distFileName" value="threeten-${version.full}.zip"/>
- <property name="tzdbBase" value="jsr-310-TZDB-all-${version.full}" />
- <property name="tzdbJarName" value="${tzdbBase}.jar" />
- <property name="tzdbJarNamePom" value="${tzdbBase}.pom" />
-
- <macrodef name="get-dependency">
- <attribute name="group" />
- <attribute name="artifact" />
- <attribute name="version" />
- <attribute name="variant" default="" />
- <attribute name="dest" />
- <sequential>
- <get
- src="${maven.repo.url}/@{group}/@{artifact}/@{version}/@{artifact}-@{version}@{variant}.jar"
- dest="@{dest}/@{artifact}-@{version}@{variant}.jar"
- verbose="true"
- usetimestamp="true" ignoreerrors="true"/>
- </sequential>
- </macrodef>
-
- <path id="main.path">
- <pathelement location="${core.main.classes}" />
- <pathelement location="${lib.main}/${tzdb.outputjar}"/>
- </path>
-
- <path id="test.commonpath">
- <pathelement location="${core.test.classes}" />
- <pathelement location="${standard.test.classes}" />
- <pathelement location="${lib.main}/${tzdb.outputjar}"/>
- <fileset dir="lib/test">
- <include name="**/*.jar" />
- </fileset>
- </path>
-
- <path id="test.path">
- <path refid="main.path" />
- <path refid="test.commonpath" />
- </path>
-
- <path id="tck.path">
- <pathelement location="${tck.implementation}" />
- <path refid="test.commonpath" />
- </path>
-
- <property name="tck.groups" value="tck" />
-
- <path id="coverage.path">
- <pathelement location="${core.main.classes}" />
- <pathelement location="${core.test.classes}" />
- <pathelement location="${standard.test.classes}" />
- <pathelement location="${lib.main}/${tzdb.outputjar}"/>
- <fileset dir="lib/test">
- <include name="**/*.jar" />
- </fileset>
- </path>
-
- <path id="emma.lib" >
- <pathelement location="${lib.coverage}/emma-2.0.5312.jar" />
- <pathelement location="${lib.coverage}/emma_ant-2.0.5312.jar" />
- </path>
-
- <!-- ==================================================================== -->
- <target name="resolve-deps">
- <mkdir dir="${lib.main}" />
- <mkdir dir="${lib.optional}" />
- <mkdir dir="${lib.test}" />
- <mkdir dir="${lib.coverage}" />
-
- <get-dependency group="org/testng" artifact="testng" version="5.8" variant="-jdk15" dest="${lib.test}" />
- <get-dependency group="emma" artifact="emma" version="2.0.5312" dest="${lib.coverage}" />
- <get-dependency group="emma" artifact="emma_ant" version="2.0.5312" dest="${lib.coverage}" />
- </target>
-
- <target name="init" depends="resolve-deps">
- </target>
-
- <target name="clean" description="clean up">
- <delete dir="${build}" />
- <delete dir="${dist}" />
- <!--delete dir="${lib.main}" failonerror="false" /-->
- <delete dir="${lib.optional}" failonerror="false" />
- </target>
-
- <!-- ==================================================================== -->
- <target name="compile-core" depends="init">
- <mkdir dir="${core.main.classes}"/>
- <javac srcdir="${core.main}" destdir="${core.main.classes}" debug="true" includeantruntime="false">
- <classpath refid="main.path"/>
- <!--compilerarg value="-Xlint" /-->
- </javac>
- <copy todir="${core.main.classes}">
- <fileset dir="${core.main.resources}" />
- </copy>
- </target>
-
- <!-- target to test if existing tzdb is out of date with respect to the input tzdb files -->
- <target name="check-tzdb">
- <dependset>
- <srcfileset
- dir="${tzdata.main}"
- includes="tzdata*.tar.gz" />
- <targetfilelist
- dir="${lib.main}"
- files="${tzdb.outputjar}" />
- </dependset>
- <available property="tzdb.available"
- file="${lib.main}/${tzdb.outputjar}" />
- </target>
-
- <target name="compile-tzdb" depends="check-tzdb,compile-core" unless="tzdb.available">
- <antcall target="force-compile-tzdb"/>
- </target>
-
- <target name="force-compile-tzdb" depends="compile-core">
- <mkdir dir="${tzdata.main.workarea}"/>
- <copy todir="${tzdata.main.workarea}">
- <fileset dir="${tzdata.main}" includes="tzdata*.tar.gz"/>
- <mapper type="glob" from="tzdata*.tar.gz" to="*/tzdb.tar.gz" />
- </copy>
- <subant genericantfile="build.xml" target="tzdb-unpack">
- <dirset dir="${tzdata.main.workarea}" includes="*" />
- </subant>
- <java classpathref="main.path" classname="javax.time.zone.TzdbZoneRulesCompiler" fork="true" failonerror="true">
- <arg line="-srcdir ${tzdata.main.workarea}" />
- <arg line="-dstdir ${lib.optional}" />
- <arg line="${tzdb.files}" />
- </java>
- <copy todir="${lib.main}">
- <fileset dir="${lib.optional}" includes="${tzdb.outputjar}"/>
- </copy>
- <delete file="${lib.optional}/${tzdb.outputjar}" />
- </target>
- <target name="tzdb-unpack">
- <echo message="${basedir}"></echo>
- <gunzip src="${basedir}/tzdb.tar.gz" />
- <untar src="${basedir}/tzdb.tar" dest="${basedir}" />
- <delete file="${basedir}/tzdb.tar" />
- </target>
-
- <target name="compile" depends="compile-core, compile-tzdb" description="compile all sources" />
-
- <!-- ==================================================================== -->
- <target name="javadoc" depends="init" description="generates javadoc for the api">
- <mkdir dir="${build.javadoc}"/>
- <javadoc sourcepath="${core.main}" destdir="${build.javadoc}"
- group="Core javax.time:javax.time.calendrical:javax.time.builder:javax.time.format:javax.time.zone:javax.time.chrono:javax.time.chrono.global"
- classpathref="main.path"
- link="http://docs.oracle.com/javase/7/docs/api/"
- stylesheetfile="${basedir}/stylesheet.css"
- windowtitle="ThreeTen date and time API"
- failonerror="true"
- use="true"
- packagenames="javax.time**/*,java.util**/*"
- overview="${core.main}/javax/time/overview.html" />
- </target>
-
- <!-- ==================================================================== -->
- <target name="run" description="Run the Usability program" depends="compile-core-tests,compile-standard-tests">
- <java classname="javax.time.UsabilityChrono"
- classpathref="test.path"/>
- </target>
-
- <!-- ==================================================================== -->
- <target name="compile-core-tests" depends="compile">
- <mkdir dir="${core.test.classes}" />
- <javac srcdir="${core.test}" destdir="${core.test.classes}" classpathref="test.path" debug="true" includeantruntime="false" />
- <javac srcdir="${core.tck}" destdir="${core.test.classes}" classpathref="test.path" debug="true" includeantruntime="false" />
- </target>
-
- <target name="compile-standard-tests" depends="compile">
- <mkdir dir="${standard.test.classes}" />
- <javac srcdir="${standard.test}" destdir="${standard.test.classes}" classpathref="test.path" debug="true" includeantruntime="false" />
- </target>
-
- <target name="test-core" depends="compile-core-tests">
- <taskdef resource="testngtasks" classpathref="test.path" />
- <testng classpathref="test.path" outputDir="${core.test.classes}" sourceDir="${core.test}" haltonfailure="true" verbose="2">
- <jvmarg value="-Xmx512M" />
- <jvmarg value="-Duser.language=en" />
- <jvmarg value="-Duser.country=UK" />
- <classfileset dir="${core.test.classes}" includes="**/Test*.class" excludes="java/util/*" />
- <classfileset dir="${core.test.classes}" includes="**/TCK*.class" excludes="java/util/*" />
- </testng>
- </target>
-
- <target name="test-standard" depends="compile-standard-tests">
- <taskdef resource="testngtasks" classpathref="test.path" />
- <testng classpathref="test.path" outputDir="${standard.test.classes}" sourceDir="${standard.test}" haltonfailure="true" verbose="2">
- <jvmarg value="-Xmx512M" />
- <jvmarg value="-Duser.language=en" />
- <jvmarg value="-Duser.country=UK" />
- <classfileset dir="${standard.test.classes}" includes="**/Test*.class" excludes="java/util/*" />
- </testng>
- </target>
-
- <target name="test" depends="test-core,test-standard" description="run tests" />
-
- <target name="check-sigtest-downloaded">
- <available property="sigtest.exists" file="${sigtest.loc}"/>
- </target>
-
- <target name="download-sigtest" depends="check-sigtest-downloaded" unless="${sigtest.exists}">
- <get
- src="${sigtest.dist.origin}"
- dest="${sigtest.dist.file}"
- verbose="true"
- usetimestamp="true" />
- <unzip
- src="${sigtest.dist.file}"
- dest="${lib.test}">
- <patternset>
- <include name="${sigtest.dist.jarloc}" />
- </patternset>
- <mapper type="flatten"/>
- </unzip>
- <delete file="${sigtest.dist.file}" />
- </target>
-
- <target name="tdtck" description="Setup task definitions for the TCK" depends="download-sigtest" >
- <taskdef name="setup-sigtest-task" classname="com.sun.tdk.signaturetest.ant.ASetup"
- classpath="${sigtest.loc}"/>
- <taskdef name="test-sigtest-task" classname="com.sun.tdk.signaturetest.ant.ATest"
- classpath="${sigtest.loc}"/>
- <property name="tck-signatures" value="${build.test}/jsr310.sig" />
- <property name="tck-rt-jar" value="${java.home}/lib/rt.jar" />
- </target>
-
- <target name="setup-sigtest"
- description="generates the signatures file from the reference implementation"
- depends="tdtck">
- <setup-sigtest-task package="javax.time" failonerror="true" apiVersion="openapi-v2"
- filename="${tck-signatures}">
- <classpath>
- <pathelement location="${tck-rt-jar}"/>
- <pathelement location="${build}/${jarName}"/>
- </classpath>
- <!--<exclude class="com.acme.openapi.NotTested"/>-->
- </setup-sigtest-task>
- </target>
-
- <target name="run-sigtest"
- description="compares the reference implementation sigtest results with a specified path"
- depends="tdtck">
- <test-sigtest-task failonerror="true" apiVersion="openapi-v2"
- filename="${tck-signatures}" backward="true" output="st_report.txt">
- <package name="javax.time" />
- <!--<exclude class="com.acme.openapi.NotTested"/>-->
- <classpath>
- <pathelement location="${tck-rt-jar}"/>
- <pathelement location="${tck.implementation}"/>
- </classpath>
- </test-sigtest-task>
- </target>
-
- <target name="runtck" depends="compile-core-tests" >
- <taskdef resource="testngtasks" classpathref="tck.path" />
- <testng classpathref="tck.path" outputDir="${core.test.classes}" sourceDir="${core.test}" haltonfailure="true" verbose="2" groups="tck">
- <jvmarg value="-Xmx512M" />
- <jvmarg value="-Duser.language=en" />
- <jvmarg value="-Duser.country=UK" />
- <classfileset dir="${core.test.classes}" includes="**/Test*.class" excludes="java/util/*" />
- </testng>
- </target>
-
- <target name="tck" depends="compile-tzdb,runtck,run-sigtest" description="run tck acceptance criteria" />
-
- <!-- ==================================================================== -->
- <macrodef name="do-coverage">
- <attribute name="runclass" />
- <attribute name="htmlout" />
- <attribute name="txtout" />
- <sequential>
- <taskdef resource="emma_ant.properties" classpathref="emma.lib" />
- <mkdir dir="${build.coverage}" />
- <emmajava libclasspathref="emma.lib"
- fullmetadata="yes"
- sourcepath="${core.main}"
- classname="@{runclass}"
- classpathref="coverage.path">
- <jvmarg value="-Xmx512M" />
- <jvmarg value="-XX:-UseSplitVerifier" />
- <filter includes="javax.time.*" excludes="*Test*, *Mock*, *Performance*, *Examples*, *AllTCK*, *Usability*" />
- <txt outfile="${build.coverage}/@{txtout}" />
- <html outfile="${build.coverage}/@{htmlout}" metrics="method:90,block:90,line:90,class:95" />
- </emmajava>
- </sequential>
- </macrodef>
-
- <target name="tck-coverage" depends="compile-core-tests,compile-standard-tests" description="tck coverage">
- <do-coverage runclass="javax.time.AllTCK" htmlout="tck.html" txtout="tck.txt" />
- </target>
-
- <target name="coverage" depends="compile-core-tests,compile-standard-tests" description="test coverage">
- <do-coverage runclass="javax.time.AllTest" htmlout="coverage.html" txtout="coverage.txt" />
- </target>
-
- <!-- ==================================================================== -->
- <target name="jar-main" depends="compile">
- <jar jarfile="${build}/${jarName}">
- <fileset dir="${core.main.classes}"/>
- </jar>
- </target>
-
- <target name="jar-main-sources">
- <jar jarfile="${build}/${jarNameSources}">
- <fileset dir="${core.main}"/>
- </jar>
- </target>
-
- <target name="jar-main-javadoc" depends="javadoc">
- <jar jarfile="${build}/${jarNameJavadoc}">
- <fileset dir="${build.javadoc}"/>
- </jar>
- </target>
-
- <target name="jar" depends="jar-main,jar-main-sources,jar-main-javadoc" description="build jar files" />
-
- <!-- ==================================================================== -->
- <target name="dist" depends="jar" description="generate the distribution">
- <copy todir="${dist.workarea}/${src}">
- <fileset dir="${src}"/>
- </copy>
- <copy todir="${dist.workarea}/lib" flatten="true">
- <fileset dir="${lib.main}" includes="${tzdb.outputjar}" />
- <fileset dir="${build}" includes="${jarName}" />
- </copy>
- <copy todir="${dist.workarea}/lib-optional" flatten="true">
- <fileset dir="${lib.optional}" includes="*.jar" />
- <fileset dir="${build}" includes="*.jar" />
- </copy>
- <delete file="${dist.workarea}/lib-optional/${jarName}" />
- <copy todir="${dist.workarea}/nbproject">
- <fileset dir="nbproject"/>
- </copy>
- <copy file=".classpath" todir="${dist.workarea}" />
- <copy file=".project" todir="${dist.workarea}" />
- <copy file="build.xml" todir="${dist.workarea}" />
- <copy file="build.properties" todir="${dist.workarea}" />
- <copy file="checkstyle.xml" todir="${dist.workarea}" />
- <copy file="LICENSE.txt" todir="${dist.workarea}" />
- <copy file="README.txt" todir="${dist.workarea}" />
- <copy file="TODO.txt" todir="${dist.workarea}" />
- <zip destfile="${dist}/${distFileName}" basedir="${dist.workarea}" />
- </target>
-
- <target name="maven.clean">
- <delete dir="${maven}" includes="**/*" failonerror="false"/>
- </target>
-
- <target name="maven" depends="maven.clean, dist">
- <mkdir dir="${maven}"/>
- <mkdir dir="${maven}/threeten"/>
- <mkdir dir="${maven}/tzdb"/>
-
- <copy todir="${maven}/threeten">
- <fileset file="${build}/${jarName}"/>
- <fileset file="${build}/${jarNameSources}"/>
- <fileset file="${build}/${jarNameJavadoc}"/>
- </copy>
- <copy filtering="true" file="maven/threeten.pom" tofile="${maven}/threeten/${jarNamePom}">
- <filterset>
- <filter token="version" value="${version.full}"/>
- </filterset>
- </copy>
- <copy file="${lib.main}/${tzdb.outputjar}" tofile="${maven}/tzdb/${tzdbJarName}"/>
- <copy filtering="true" file="maven/jsr-310-TZDB-all.pom" tofile="${maven}/tzdb/${tzdbJarNamePom}">
- <filterset>
- <filter token="version" value="${version.full}"/>
- </filterset>
- </copy>
-
- <checksum algorithm="sha1">
- <fileset dir="${maven}/threeten"/>
- <fileset dir="${maven}/tzdb"/>
- </checksum>
-
- <jar destfile="${maven}/${jarBase}-maven-bundle.jar" basedir="${maven}/threeten" includes="${jarBase}*"/>
- <jar destfile="${maven}/${tzdbBase}-maven-bundle.jar" basedir="${maven}/tzdb" includes="${tzdbBase}*"/>
- </target>
-
- <target name="fixup" description="fixes code to OpenJdk standards">
- <!-- this does NOT change line endings to unix -->
- <fixcrlf srcdir="." includes="**/*.java" eof="remove" fixlast="true" tab="remove" tablength="4" javafiles="true" />
- </target>
-
- <target name="checkstyle" description="checkstyle to 310 standards">
- <exec executable="checkstyle">
- <arg line="-c checkstyle.xml -r ${core.main} -r ${core.test}"/>
- </exec>
- </target>
-
- <!-- ==================================================================== -->
- <target name="examples" depends="compile-core-tests,compile-standard-tests" description="outputs some examples to system out">
- <java classname="javax.time.Examples" classpathref="test.path" fork="true"/>
- </target>
-</project>
View
126 checkstyle.xml
@@ -1,126 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN" "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
-
-<!--
- This configuration file was written by the eclipse-cs plugin configuration editor
--->
-<!--
- Checkstyle-Configuration: ThreeTen
- Description: none
--->
-<module name="Checker">
- <property name="severity" value="warning"/>
- <module name="TreeWalker">
- <property name="tabWidth" value="4"/>
- <module name="FileContentsHolder"/>
- <module name="ConstantName">
- <property name="format" value="^[A-Z_][A-Z0-9]*(_[A-Z0-9]+)*$"/>
- </module>
- <module name="AvoidStarImport"/>
- <module name="EmptyBlock">
- <property name="tokens" value="LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_IF,LITERAL_TRY,LITERAL_WHILE,STATIC_INIT"/>
- </module>
- <module name="EmptyForInitializerPad">
- <property name="option" value="space"/>
- </module>
- <module name="EmptyForIteratorPad">
- <property name="option" value="space"/>
- </module>
- <module name="EqualsHashCode"/>
- <module name="IllegalImport"/>
- <module name="IllegalInstantiation"/>
- <module name="JavadocType">
- </module>
- <module name="JavadocMethod">
- <property name="scope" value="package"/>
- <property name="excludeScope" value="anoninner"/>
- <property name="allowUndeclaredRTE" value="true"/>
- </module>
- <module name="JavadocVariable">
- <property name="excludeScope" value="anoninner"/>
- </module>
- <module name="LeftCurly"/>
- <module name="LineLength">
- <property name="ignorePattern" value="^ *\* *[^ ]+$"/>
- <property name="max" value="200"/>
- </module>
- <module name="LocalFinalVariableName"/>
- <module name="LocalVariableName"/>
- <module name="MemberName"/>
- <module name="MethodLength">
- <property name="max" value="250"/>
- </module>
- <module name="MethodName"/>
- <module name="ModifierOrder"/>
- <module name="NeedBraces">
- <property name="tokens" value="LITERAL_DO,LITERAL_ELSE,LITERAL_IF,LITERAL_WHILE"/>
- </module>
- <module name="NoWhitespaceAfter"/>
- <module name="NoWhitespaceBefore">
- <property name="allowLineBreaks" value="true"/>
- <property name="tokens" value="DOT"/>
- </module>
- <module name="OperatorWrap">
- <property name="option" value="eol"/>
- <property name="tokens" value="ASSIGN, DIV_ASSIGN, PLUS_ASSIGN, MINUS_ASSIGN, STAR_ASSIGN, MOD_ASSIGN, SR_ASSIGN, BSR_ASSIGN, SL_ASSIGN, BXOR_ASSIGN, BOR_ASSIGN, BAND_ASSIGN"/>
- </module>
- <module name="PackageName"/>
- <module name="ParameterName"/>
- <module name="ParameterNumber">
- <property name="max" value="20"/>
- </module>
- <module name="ParenPad"/>
- <module name="RedundantImport"/>
- <module name="RedundantModifier"/>
- <module name="RightCurly"/>
- <module name="SimplifyBooleanReturn"/>
- <module name="StaticVariableName"/>
- <module name="TypeName"/>
- <module name="TypecastParenPad"/>
- <module name="UpperEll"/>
- <module name="VisibilityModifier">
- <property name="packageAllowed" value="true"/>
- </module>
- <module name="WhitespaceAfter"/>
- <module name="WhitespaceAround">
- <property name="tokens" value="ASSIGN, BAND, BAND_ASSIGN, BOR, BOR_ASSIGN, BSR, BSR_ASSIGN, BXOR, BXOR_ASSIGN, COLON, DIV, DIV_ASSIGN, EQUAL, GE, GT, LAND, LCURLY, LE, LITERAL_ASSERT, LITERAL_CATCH, LITERAL_DO, LITERAL_ELSE, LITERAL_FINALLY, LITERAL_FOR, LITERAL_IF, LITERAL_RETURN, LITERAL_SYNCHRONIZED, LITERAL_TRY, LITERAL_WHILE, LOR, LT, MINUS, MINUS_ASSIGN, MOD, MOD_ASSIGN, NOT_EQUAL, PLUS, PLUS_ASSIGN, QUESTION, RCURLY, SL, SLIST, SL_ASSIGN, SR, SR_ASSIGN, STAR, STAR_ASSIGN"/>
- </module>
- <module name="AnnotationUseStyle"/>
- <module name="MissingDeprecated"/>
- <module name="PackageAnnotation"/>
- <module name="SuppressWarnings"/>
- <module name="JavadocStyle"/>
- <module name="ClassTypeParameterName"/>
- <module name="MethodTypeParameterName"/>
- <module name="ImportOrder">
- <property name="option" value="top" />
- </module>
- <module name="GenericWhitespace"/>
- <module name="MethodParamPad"/>
- <module name="CovariantEquals"/>
- <module name="DefaultComesLast"/>
- <module name="ExplicitInitialization"/>
- <module name="FallThrough"/>
- <module name="JUnitTestCase"/>
- <module name="FinalClass"/>
- <module name="HideUtilityClassConstructor"/>
- <module name="InterfaceIsType"/>
- <module name="MutableException"/>
- <module name="ArrayTypeStyle"/>
- </module>
- <module name="SuppressionFilter">
- <property name="file" value="${basedir}/suppressions.xml"/>
- </module>
- <module name="SuppressionCommentFilter">
- <property name="offCommentFormat" value="CSOFF\: ([\w\|]+)"/>
- <property name="onCommentFormat" value="CSON\: ([\w\|]+)"/>
- <property name="checkFormat" value="$1"/>
- </module>
- <module name="FileLength">
- <property name="max" value="3000"/>
- </module>
- <module name="JavadocPackage">
- <property name="allowLegacy" value="true" />
- </module>
- <module name="FileTabCharacter"/>
-</module>
View
34 maven/jsr-310-TZDB-all.pom
@@ -1,34 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
-
- <!-- This pom is provided for PRIVATE USE ONLY -->
- <!-- It is not intended to permit ThreeTen to be publicly available via maven -->
-
- <modelVersion>4.0.0</modelVersion>
- <groupId>javax.time</groupId>
- <artifactId>jsr-310-TZDB-all</artifactId>
- <packaging>jar</packaging>
-
- <name>ThreeTen time-zone database</name>
- <version>@version@</version>
-
- <url>http://threeten.sourceforge.net/</url>
-
- <scm>
- <url>https://github.com/ThreeTen/threeten.git</url>
- <connection>scm:git:git@github.com:threeten/threeten.git</connection>
- <developerConnection>scm:git:git@github.com:threeten/threeten.git</developerConnection>
- </scm>
-
- <mailingLists>
- <mailingList>
- <name>Threeten Develop Mailing List</name>
- <post>threeten-develop@lists.sourceforge.net</post>
- <subscribe>https://lists.sourceforge.net/lists/listinfo/threeten-develop</subscribe>
- <unsubscribe>https://lists.sourceforge.net/lists/listinfo/threeten-develop</unsubscribe>
- <archive>http://sourceforge.net/mailarchive/forum.php?forum_name=threeten-develop</archive>
- </mailingList>
- </mailingLists>
-</project>
View
46 maven/threeten.pom
@@ -1,46 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
-
- <!-- This pom is provided for PRIVATE USE ONLY -->
- <!-- It is not intended to permit ThreeTen