Skip to main content

EDR Feedback - Validity of Currencies

  4 posts   Feedicon  
Replies: 3 - Last Post: June 09, 2013 23:50
by: keilw
showing 1 - 4 of 4
Posted: May 23, 2013 07:47 by Anatole

Mark Davis (Google) wrote:

What we provide in ICU is a way to iterate through, for any currency, the countries where it is (or was) a valid currency, and in those countries, the time period(s) where it was valid (these are "period(s)", since they may be disjoint). With that data being present, there can also be some convenience methods, like:

java.lang.Long getValidFrom(String countryCode); // earliest point at which valid in that country
java.lang.Long getValidUntil(String countryCode); // latest point at which valid in that country

although the Java doc should acknowledge that that doesn't guarantee that the period is contiguous.

So there are different types of validities at the same time, but with different UTC timstamps like

  • Validity of a currency for a country
  • Validity of a currency as defined by a “standard” like ISO
  • Validity of a currency as defined by some organization like IMF, Credit Card companies

These should be reflected in the current API and may also include separating validity information from the CurrencyUnit interface. This topic should discuss about how to achieve this best.

Posted: May 23, 2013 14:41 by vgrazi
How is this going to be maintained over time, as things change?
Posted: May 23, 2013 15:47 by Anatole
Basically only the mapping to countries may be added as a language feature, which is also provided by the ISO standard.
The proposal mentioned at the EC meeting is to implement some similar mechanism as also used for 310 (e.g. time zones), I have to look at it in detail, but this might be a feasible approach.
Posted: June 09, 2013 23:50 by keilw
That's a good point.
As mentioned in the Mailing list thread, the best possible compatibility with existing extension mechanisms in java.util.Currency like the "currency.properties" file shall be preserved.

Money and Currency won't be the only area where Java 9 needs to come up with a more flexible, yet secure update mechanism for parts of the Java Platform itself.

Also because the final non-extensible nature of many parts makes change not to be in the nature of the API, we won't find too many true extension mechanisms in JSR 310 as of now. All TimeZone data seems more or less directly derived from the good old java.util.Date, but unlike Currency there is no extension mechanism per se. You can only extend Date/Time by witing your own implementation or extension to either the whole series of Temporal, TemporalUnit, etc. or java.util.Calendar.
The latter worked for ages, I provided an extension that's fully compatible with java.util.Calendar but supports things like QuarterOfTheYear, etc. around 12 years ago! Still would be the same if you wanted e.g. a new calendar system for India, China or Africa. there is no generic plugin or even properties file for that provided by either java.util or java.time elements.
Replies: 3 - Last Post: June 09, 2013 23:50
by: keilw
 
 
Close
loading
Please Confirm
Close