Issue Details (XML | Word | Printable)

Key: JAVAMONEY-14
Type: New Feature New Feature
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: atsticks
Reporter: atsticks
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javamoney

Support different time dimensions

Created: 01/Feb/13 07:14 AM   Updated: 09/Mar/14 04:44 PM   Resolved: 09/Mar/14 04:44 PM
Component/s: API, Spec: Specification
Affects Version/s: None
Fix Version/s: 0.5

Time Tracking:
Not Specified

Tags: date time timestamp time_handling
Participants: atsticks, chrispheby and keilw


 Description  « Hide

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
use solve this as follows:

  • usage of java.lang.Long for modelling UTC timestamps, where as the value denotes the ms starting from 1.1.1970 00:00.
  • when a value is not define null may be returned.


chrispheby added a comment - 05/Feb/13 03:20 PM

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


keilw added a comment - 05/Feb/13 06:33 PM - edited

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.
Imagine some traders rely on real time, this method may actually be used, while other cases could find miliseconds sufficient. So not sure, if the "timestamp" should be too restricted. An implementation of an interface with one or more timestamps could handle the difference in nanos, while others may use milis, both are long.


keilw added a comment - 09/Mar/14 04:44 PM

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.