Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 326147

Summary: Long as Attribute Type
Product: [Modeling] AMP Reporter: Jonas Ruttimann <jonas.ruettimann>
Component: AMF UIAssignee: Miles Parker <milesparker>
Status: RESOLVED WONTFIX QA Contact: Miles Parker <milesparker>
Severity: enhancement    
Priority: P3    
Version: 0.8.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Jonas Ruttimann CLA 2010-09-24 09:44:00 EDT 
Build Identifier: 0.8.0

In my model I'd like to use time stamps as they are being used in Java. Typically these are Long numbers, representing milliseconds. So with the available type Integer I'll experience a loss of precision. I'd rather use Long.

Reproducible: Always
Comment 1 Miles Parker CLA 2010-09-24 12:43:52 EDT 
Integer ~= Java.Integer

Instead Integer is meant in the number theoretical sense to have arbitrary precision that is realized for a particular code generation. It's just an accident of history that the Java usage is so well known. Its clearer with "Real" because that doesn't elide the issue of precision with that of classification.

So they could short, long, BugNum, whatever. So that's the theory, the problem is that we don't have a generation model yet that can support generation at different levels of precision. That wouldn't be super difficult to hack, but at the same time I'd rather have good testing in place before we change that.

So I'm going to mark this one as Won't Fix -- not because I don't think the issue is important but because we need a more general way to deal with it. We could open a separate one for that.
Comment 2 Miles Parker CLA 2010-09-24 12:44:45 EDT 
Marking won't fix per above please feel free to open a more general bug on this.
Comment 3 Miles Parker CLA 2010-09-24 12:54:15 EDT 
BTW, I realize that this isn't that satisfactory, but as a work around you could specify a start time in UTC for the model as a whole and then get the actual time as an offset of that. In some ways that could be more usable and clear as you would have granularity appropriate to your model

For example, if you had a model that was doing financial forecasting where your finest level of granularity is day, then you could define a level of granularity as "Days in Millis" = 24*60*60*1000. Then from that you could determine your start date as the UTC for say January 1, 2010 as startTime. If every model step is then one day then you multiple "Time Now" * "Days in Millis" to get millis time. Of course, you would have to handle the result of that in Java.

This all gets into the overall issue of how the time model will function so we should keep this in mind when working on that.