Thanks for the quick response.
On Wed, Jan 30, 2013 at 3:31 PM, Anatole Tresch <atsticks@...>
some point from my side:
1) Timestamp Modelling:
I created Calendar improvements and extensions as far back as 1997 (just after Java 1 came out, no evidence of Joda, which according to SF.net
started 2002 then) in a SF project called SDJ (Survey Developer Library 4 Java). Open Sourced on SF by 2001 after it was used for numerous clients and projects internally.
One of the challenges were custom durations, along the line of what 310 added very recently, QUARTER_OF_YEAR, HALF_OF_YEAR, or others like "fortnight", often commercially used by British banks and businesses at least, guess that's why 310 hasn't got it, given UK is not 80% of the World any more?<347.gif>
There are multiple getters, setters and other method calls, can't tell you of the top of my head, but there are things e.g. the SDJ custom extension of GregorianCalendar (compatible with java.util.Calendar base class despite all of its quirks) had to do, before e.g. a quarter or other duration was calculated correctly, including all the other fields you mentioned.
As a Spec the JSR cannot rely on things that are not wide enough part of the Java Platform already, and that even in Java 8 only a small (considering the number of runtimes or CPUs/cores if you want, SE Desktop and even EE will play a lesser role) number of Java runtimes will come with.
For implementations, this could be done by using 310, should that address all the problems you mentioned (maybe someone best created a Unit Test or similar test case for these requirements?<347.gif>) for implementations under Java 6 or 7, I'm afraid, the only alternatives could either be JodaTime, that "Backport" of 310, or similar.
And given none of these have even the slightest chance of a common basis, we would have to use Generics to avoid API with incompatible types. Java itself and all parts like Lambda do that everywhere.
The only other alternative would be long values to capture e.g. a Timestamp.
Btw, if you look at a page like this:
The current implementation handles dates in a wide range, from 4716 BC up to 5000000 AD. Dates outside of that range will throw an IllegalArgumentException. This range should be broadened in the future.
Although much of the JavaDoc got lost in recent JDKs, I doubt, the functionality was seriously broken, so the first year you can handle with Calendar (if you adjust ALL fields properly) is clarly not 1520.
Does 4716 BC till 5000000 AD sound, like we can't live with that?<329.gif>
> There should be a good reason, interfaces in public APIs like 310 and others don't simply extend Serializable, nor others like Comparable.
That was never intended.
> The Temporal JavaDoc probably shows how this could look like for both:
> This interface places no restrictions on implementations and makes no guarantees about their thread-safety. All implementations must be
So I try to be more clear: the question is, if should define the serialization format. Of course, we will require from the spec/javaDoc that implementations must be seriazable/comparable and the TCK should also check that.
The question was if we should additionally define how a value must be serialized, e.g.
- two longs for the decimal parts (the first one also containing the sign)
- the internal precision (int)
- The implementation class (String)
The current spec makes a proposal about this, which is already marked as not optimal, or inappropriate. But before starting a discussion on the format, we have to decice, if we want to define explicitly a format at all or just define what values must be serialized, but leave the concrete format to the implementations.
So now I will stop for some times, leaving space for other opinions ;-)