New

I am a developer from Nigeria. We could connect as i learn a lot on
this project. Thanks

RE: JSR 310: Date and Time API

Hi,

I have noted a few points on which your expert opinion is highly appreciated:-
URL:- http://threeten.svn.sourceforge.net/viewvc/threeten/trunk/threeten/src/main/java/javax/time/Duration.java?revision=1443

1) There are functions such as shown below public Duration minusNanos(long nanosToSubtract) {

 Which do not have a check for NaN or a divide by zero error. Though this could be run-time, there are high
chances that an absence of a throws or a try-catch can cause issues. We might want to have a look at it.

2) I was wondering if we could make our Date Conversion functions smart enough to retain and convert dates (
based on the flag parameter).

I propose that we add a function parameter in any of our date conversion functions..say smartConvert . If
this is set to true , we will convert the date
Or obtain the date processing results in such a way that we get the most accurate of results.

For e.g. say we need to find the day from the given date. Now, say the date is long but the conversion is taken
from Date String, it can end of loosing the date's accuracy ( in terms of seconds or milliseconds).

Why don't we check if get the values correctly, convert the date and see which is closer. We need to use a more
approximation ..

For e.g.) 12 Feb 1983 11.59 PM ..Say we get the day for this. Now, this will return 12 for this. Hwoever, it is
almost 1 minute left from 13 in actual.
Why don't we put in a flag "smartConvert" and if set to true, we put in a mechanism to:-
1) check the format to ensure that we do not loose out on milliseconds and seconds that maybe crucial in date
conversions for apps that need high accuracy.
2) if yes, then get the practically best possible approximation( smart conversion) rather than just
fetching the day portion and giving the answer.

RE: JSR 310: Date and Time API

Hello,

1) I
I was going through the code on the URL:-

http://java.net/projects/jsr-310/sources/svn/content/trunk/jsr-310-ri/src-openjdk/main/java/java/util/Calendar.java?rev=1339

Why are the methods not having a Null-Pointer Exception or even just a general exception handler? I think
this might cause issues in some of these methods in this project.

/**
     * Sets the instant represented by this <code>Calendar</code> to be the same as
     * the provided <code>Instant</code>.
     * <p>
     * An { <at> link InstantProvider} is a simple interface that is implemented by
     * numerous date-time classes.  It provides a mechanism to convert those
     * objects to an instance of <code>Instant</code> which is then used to
     * set the time of this <code>Calendar</code>.
     * <p>
     * <code>Instant</code> uses a precision of nanoseconds, whereas
     * <code>Calendar</code> uses a precision of milliseconds.  The conversion will
     * drop any excess precision information as though the amount in nanoseconds
     * was subject to integer division by one million.
     * <p>
     * <code>Instant</code> can store points on the time-line further in the
     * future and further in the past than <code>Calendar</code>.  In this scenario,
     * this method will throw an exception.
     * <p>
     * Note: If the epoch millis resolves to Long.MAX_VALUE</code> or <code>Long.MIN_VALUE</code>

Discussion started on the ThreeTen list!

All,
Discussion has now staretd on the threeten-develop list. Please sign
up to that list to follow future discussion.
https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2292

Mailing list signup:
https://sourceforge.net/mail/?group_id=386712
ThreeTen principles: "This project works on trust and respect for the
public good. Contributions to project discussion (including, but not
limited to, mailing lists and wiki edits) is publicly available
information which may be used by anyone in any way forever. "

thanks
Stephen

Announcement: Moving JSR-310 to ThreeTen

All,
With the impending move from java.net to Kenai, and the recent JCP
issues, I took to opportunity to re-evaluate the status of JSR-310.

The full details are on my blog:
http://www.jroller.com/scolebourne/entry/what_about_jsr_310

In summary, JSR-310 is continuing, but treating the JSR process as a
necessary tool to reach Java SE 8 rather than the prime focus.

As part of this, I have moved the project from java.net to
sourceforge. I have also taken the opportunity to separate more
clearly the project and the JSR, creating the ThreeTen project. For
the most part this has no impact on how the project is run, but it
does allow us to create a specification separate from the JCP should
we desire it.

Thus, going forward, the ThreeTen project is the reference
implementation of JSR-310:
https://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen

All discussion about the ThreeTen project, and JSR-310 will occur on
the develop mailing list at sourceforge.

THIS LIST AND PROJECT WILL SOON BE TERMINATED

The new project has more explicit rules for contributions to
discussions and code:
https://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen#Legal_bit

Period.totalXxx() behavior inconsistence

I found some inconsistence on the totalXxx() methods of Period class. While 
some methods return the actual total amount of units of that period, others 
return the specidied amount.

If you try to execute this code:

public class PeriodGetXxxTest {

    public static void main(String... args) {
        LocalDate christmas2010 = LocalDate.of(2010, 12, 25);
        LocalDate myBirthDate = LocalDate.of(1980, 11, 16);

        Period timeBetweenBirthAndMy31thChristmas = 
Period.between(myBirthDate, christmas2010);
        System.out.println(timeBetweenBirthAndMy31thChristmas);
        System.out.println(timeBetweenBirthAndMy31thChristmas.totalMonths());
        System.out.println(timeBetweenBirthAndMy31thChristmas.totalDaysWith24HourDays());
    }

}

... in the console you can read:

P30Y1M9D
361
9

... which makes inconsistence between the two .totalXxx() methods, where one 
actually returns the total amount of months, while the other returns the 
specified amount of days .

adding UTCDateTime class

I'm writing to investigate the possibility of adding a UTCDateTime
class to JSR-310 for a DateTime that is defined as UTC.

I write Java for use with databases, and I deal almost exclusively
with DateTime values stored and retrieved in UTC. I believe that UTC
DateTimes are a special case that are used so frequently that a
special class is justifiable.

A UTCDateTime class would provide the same functionality as a
ZonedDateTime, but it would offer some benefits:
* enforce that a DateTime field is zoned UTC
* improvements in performance
* smaller size in memory

If UTCDateTime can be included, I will be happy to contribute code for
it. I welcome any feedback on this idea.

Thanks,
David Momper

Version 0.6.3

I've cut a version of 310 to mark our current position. The change log
since 0.6.2 is as follows (yes, its a little cryptic...):

Stephen

- 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)

Status 2010-12-02

This is a status update of tasks on the TODO list. Clearly it will
take a while to work through these issues, but that is what is
necessary to release.

If there are any concerns on specific items (or other things not
listed), please start a new thread.

Stephen

Status of JSR-310, 2010-12-02
=============================

The core API classes remain relatively stable, although non core
methods continue to change.

The following items are on the TODO list:

- What to do with MathUtils?
This is a class of code that is not specific to 310, but is required.
Simply adding the code to java.util.Math is insufficient, and 310
needs to run on Java 6 and maybe 5.

- Instant parse/toString
The toString/parse methods need implementing.
They cannot just reuse the formatting code, as they cover a greater
range of numbers.

- UTC leap second rules
The UTC leap second rules are in a manually edited file.
These should be moved to a better format and location.

Migrating to new Java.net platform

Handling non-ISO calendar dates seamlessly?

  Hi,

I have a question about handling dates in different calendar systems. 
For example, with the current java.util.Calendar API, you'll get a 
GregorianCalendar in US locale and a Thai Buddhist calendar in Thai 
locale. Then, you could write the following program.

public class Traditional {
     public static void main(String[] args) {
         add100days(Calendar.getInstance(Locale.US));
         add100days(Calendar.getInstance(new Locale("th", "TH")));
     }

     private static void add100days(Calendar cal) {
         cal.add(DAY_OF_YEAR, 100);
         System.out.printf("%d-%03d%n", cal.get(YEAR), cal.get(DAY_OF_YEAR));
     }
}

Its output would look like this:

2011-043
2554-043

How could the same thing be done with the JSR 310 API? (In this case 
there should be an assumption that the difference between the Gregorian 
and Thai Buddhist calendars is only the year difference, which would be 
common in many applications.)

Thanks,
Masayoshi