Skip to main content

[JIRA] Issue Comment Edited: (JAVAMONEY-14) Support different time dimensions

  • From: "keilw (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [JIRA] Issue Comment Edited: (JAVAMONEY-14) Support different time dimensions
  • Date: Tue, 5 Feb 2013 18:47:53 +0000 (GMT+00:00)
  • Auto-submitted: auto-generated


    [ 
http://java.net/jira/browse/JAVAMONEY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355241#action_355241
 ] 

keilw edited comment on JAVAMONEY-14 at 2/5/13 6:46 PM:
--------------------------------------------------------

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.

      was (Author: keilw):
    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.getMillis() 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.
  
> Support different time dimensions
> ---------------------------------
>
>                 Key: JAVAMONEY-14
>                 URL: http://java.net/jira/browse/JAVAMONEY-14
>             Project: javamoney
>          Issue Type: New Feature
>          Components: Spec: conversion, Spec: core, Spec: specification
>            Reporter: atsticks
>            Assignee: atsticks
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[JIRA] Created: (JAVAMONEY-14) Support different time dimensions, also before 1.1.1970

atsticks (JIRA) 02/01/2013

[JIRA] Updated: (JAVAMONEY-14) Support different time dimensions

atsticks (JIRA) 02/01/2013

[JIRA] Updated: (JAVAMONEY-14) Support different time dimensions

atsticks (JIRA) 02/01/2013

[JIRA] Assigned: (JAVAMONEY-14) Support different time dimensions

atsticks (JIRA) 02/01/2013

[JIRA] Commented: (JAVAMONEY-14) Support different time dimensions

chrispheby (JIRA) 02/05/2013

[JIRA] Commented: (JAVAMONEY-14) Support different time dimensions

keilw (JIRA) 02/05/2013

[JIRA] Issue Comment Edited: (JAVAMONEY-14) Support different time dimensions

keilw (JIRA) 02/05/2013

[JIRA] Updated: (JAVAMONEY-14) Support different time dimensions

atsticks (JIRA) 02/16/2013
 
 
Close
loading
Please Confirm
Close