[JAVAMONEY-14] Support different time dimensions Created: 01/Feb/13 Updated: 05/Feb/15 Resolved: 09/Mar/14
|Component/s:||API, Spec: Specification|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Tags:||date, time, time_handling, timestamp|
This JSR must handle different date and time aspects, such as timestamps, time durations or time periods. It was agreed that JSR 310 basically would be the way to go. Nevertheless, it would be useful to have a solution that is more compatible with JDK releases prior to SE 8. It was decided to
|Comment by chrispheby [ 05/Feb/13 ]|
I still think that timestamp since 1970 is not appropriate. Actually we don't need full millisecond precision so if we must use long, something like day from a reference point as a long would be better... can't go back too far it gets complicated.
I don't see a problem with depending on JSR 310. Just as Stephen is doing, we can provide a backport which depends on JSR310 backport if necessary
|Comment by keilw [ 05/Feb/13 ]|
Based on recent statements by Oracle about Java (SE) 8 and its Profiles, beside nobody from Oracle having officially confirmed 310's inclusion into Java 8 e.g. at JFokus just now (the profiles were explicitely confirmed there) the API, even the Convert module should refrain from direct references to elements of 310. The backport isn't acceptable for a JSR at all, as elements of java.* or javax.* must not use outside APIs like org.apache., org.eclipse. or any other external library such as org.threeten (the current package for this backport)
Unless some generic value or the smallest denominator (like java.util.Date, likely to be in almost EVERY SE 8 Profile, while java.time probably will only be optional or part of the Biggest SE 8 Profile) can be found, either long or int beside the equivalent wrapper types are the most sensitive option now.
Some implementations (also considering how Profiles work in SE 8 and if Java 8 should be the minimal version?) could internally use 310 to calculate something, but the "Spec" part of the API shall store it as long. Whether that's a timestamp like Sytem.currentTimeMillis() or some other interval, that's up to JavaDoc in this case to spefify or suggest. It may actually be up to an implementation in some cases, how to treat such timestamp. If an timespan is required, 2 longs can be used.
Probably lesser known, but since Java 5, there is a System.nanoTime() method, used e.g. by Concurrency, UI elements like Swing and a few other places, especially Random.
|Comment by keilw [ 09/Mar/14 ]|
Long (or long where null is not an issue) is used for UTC timestamps for various reasons. Independence from system time especially in business critical environments (like Real Time Trading) is probably the most important reason NOT to use System.getTimeInMillis() or equivalents like JSR-310 provides from Java 8.