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.