Skip to main content

[JSR-354] Re: Validity Dates for CurrencyValidity

  • From: Werner Keil <werner.keil@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Validity Dates for CurrencyValidity
  • Date: Thu, 8 Aug 2013 14:52:15 +0200

Looking at 2 Duration classes of JavaFX
https://bitbucket.org/openjfxmirrors/openjfx-8-master-rt/src/a01e2111906eba62052571e711ef1c430070fefb/javafx-common/src/javafx/util/Duration.java?at=default
and the 310 BP
https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threeten/bp/Duration.java

(almost 3x more LOC for a class that effectively does the same[?]) we'd
probably best add an implementation of such Timeframe/Duration or whatever
we might call it interface (just not exactly the same names as in JavaFX or
310 I'd say[?]) into the RI. In future (similar to what we prepared e.g. the
"Functional" interfaces) this could in an SE8+ only environment extend
TemporalAmount.

Werner

On Thu, Aug 8, 2013 at 2:22 PM, Werner Keil <werner.keil@...> wrote:

> Hi Anatole,
>
> You mostly refer to
> https://github.com/JavaMoney/javamoney/blob/master/money-api/ext/src/main/java/javax/money/ext/ValidityInfo.java
> I assume.
>
> For starters I would stick to Calendar, not pass GregorianCalendar
> explicitely.
> See
> http://marxsoftware.blogspot.dk/2013/05/jdk-8-calendar-builder.html
> Java 8 has at least as many changes to java.util.Calendar as it did with
> e.g. 310 (which only offers the same range of features anyway) plus
> Calender.Builder allows to use 310 Instant type if you're under Java 8 and
> it'll return the same there, so it IS already compatible with 310 that way.
> I don't see much value in adding an interface here, unless (and we had to
> do that under Java 7) we really want to extend java.util.Date or Calendar
> in a way I did with EnhancedCalendar of SDJ
> http://sdj.cvs.sourceforge.net/viewvc/sdj/sdj3/sdj-core/src/java/net/sf/sdj/util/EnhancedCalendar.java?view=markup
>
> Allowing to extend GregorianCalendar or any other Calendar this interface
> in SDJ theoretically would allow different implementations like some Joda
> types now, too (while EnhancedCalendar goes a bit further back, first
> introduced around 1996/7[?])
>
> Also the arguments passed to ValidityInfo as opposed to other interfaces
> may be long primitive rather than the wrapper class Long, couldn't it?
>
> Regardless of whether we'd stick to UTC timestamps plus Calendar or
> somehow substituted them (having to implement those essentially by
> extending Calendar, Date or both) the wording of "Start - End" vs. "From -
> To" in ValidityInfo should be improved. Especially with conversion and
> factories along the lines of from(), of() or to() I'd find it more easy to
> distinguish if we used getStart() and getEnd() possibly with some type like
> "Date" in the method name, what do you think?
>
> To make sense of possible future connections to java.time, only a stub for
> TemporalAmount seems useful, everything else just encapsulates a timestamp,
> even if you used a wrapper around Calendar.
>
> So a ValidityDuration, ValidityPeriod, ValidityTimeframe or something
> similar could be reasonable.
> You might use similar tricks as in
>   public <C extends Calendar> C getFrom(Class<C> type) {
>
> and if the return type was <T extends TimeFrame> this could allow multiple
> implementations of such interface, e.g. one backed by JDK Date or Calendar,
> while other implementations may use JodaTime or JSR 310 in an appropriate
> (SE8+) environment.
>
> Having said that, I hope you see the obvious (which is why I called it
> TimeFrame, not ValidityTimeframe) that this "drop-in" for TemporalAmount
> should if we really go down that path also apply to ExchangeRate in the
> "convert" module, not just in "ext" or packages within that module. That'll
> be more consistent, else stick to UTC timestamps everywhere.
>
> WDYT?
>
> On Thu, Aug 8, 2013 at 1:06 PM, Tresch Anatole (KGVA 55) <
> anatole.tresch@...> wrote:
>
>> Hi Werner****
>>
>> ** **
>>
>> So summarizing you you would go for the option (which I also prefer):****
>>
>> ** **
>>
>> **·         **write a *ValidityDate* class equivalent to *LocalDate*,
>> which could
>> implement JSR-310 interfaces later.****
>>
>> ** **
>>
>> I think the other thing is just a bug, which happens unfortunately, when
>> you write software…****
>>
>> ** **
>>
>> Regards,****
>>
>> Anatole****
>>
>> ** **
>>
>> Anatole Tresch****
>>
>> *CREDIT SUISSE AG*
>>
>> Information Technology | Java Core Framework & Support, KSXK 23****
>>
>> Zollstrasse 20/36 | 8070 Zürich | Switzerland****
>>
>> Phone +41 44 334 03 89****
>>
>> anatole.tresch@... | www.credit-suisse.com****
>>
>> ** **
>>
>> *From:* Werner Keil [mailto:werner.keil@...]
>> *Sent:* Thursday, August 08, 2013 13:01
>> *To:* jcurrency_mail@...
>> *Subject:* [JSR-354] Re: Validity Dates for CurrencyValidity****
>>
>> ** **
>>
>> We appreciate the effort, but as I also hear from Oracle in various EG
>> calls, no sane company will use Java 8 for another decade Oracle Fusion
>> Middleware 12c, the brand new "Cloud" series is based on Java EE 6, hence
>> it's Java SE 6, too (despite what pages like this say
>http://www.oracle.com/technetwork/java/eol-135779.html but if you have
>> licensed either Java SE 6 or bought Fusion Middleware products for Hundreds
>> of Thousands of Pounds or Dollars a year, you get support and even patches
>> for 20 years, too, if you need, I worked for BEA Support and some of the
>> biggest British companies used WLP 4 paying dedicated staff a few Mio. £
>> then)****
>>
>> ** **
>>
>> So JSR-310 could become relevant as soon as Java EE 8 is broader adopted,
>> no sooner than that I'm afraid. Baking it into the spec is unacceptable,
>> future versions of RI or implementing solutions may do so, e.g. if they use
>> only SE functionality.****
>>
>> ** **
>>
>> And speaking of its precursor, JodaTime, I just happen to work on a
>> support issue in our DevOps team around LogStash. It also uses JodaTime
>> underneath.****
>>
>> ** **
>>
>> And using the same DateTimeFormatter LogStash ends up getting at least
>> two different kinds of exceptions for the same problem (using "h" instead
>> of "H" in some date patterns) one would be****
>>
>> ** **
>>
>> java.lang.IllegalArgumentException: Invalid format: "Tue Apr 02 *13*:47:40
>> 2013"****
>>
>> the other****
>>
>> org.joda.time.IllegalFieldValueException: Cannot parse "Sun Aug  4 
>> *13*:06:41
>> UTC 2013": Value 13 for clockhourOfHalfday must be in the range [1,12]***
>> *
>>
>>         at
>> org.joda.time.field.FieldUtils.verifyValueBounds(FieldUtils.java:218)****
>>
>>         at
>> org.joda.time.field.ZeroIsMaxDateTimeField.set(ZeroIsMaxDateTimeField.java:85)
>> ****
>>
>>         at
>> org.joda.time.format.DateTimeParserBucket$SavedField.set(DateTimeParserBucket.java:483)
>> ****
>>
>>         at
>> org.joda.time.format.DateTimeParserBucket.computeMillis(DateTimeParserBucket.java:366)
>> ****
>>
>>         at
>> org.joda.time.format.DateTimeFormatter.parseDateTime(DateTimeFormatter.java:854)
>> ****
>>
>> ** **
>>
>> So while JSR 310 fortunately got quite a bit trimmed and simplified
>> thanks to Roger and Oracle, it still contains a few of the "maze" JodaTime
>> offers with so many different ways to do things that most Open Source
>> projects (or commercial companies where they dare to use it) run into
>> similar problems as LogStash. You do the same thing, even using the same
>> class and get two rather different error messages for the same reason,
>> because your hour is 13:30 instead of 1:30pm****
>>
>> ** **
>>
>> Not to mention, Java 8 does offer java.text.DateFormat just as well and
>> it won't return a Joda/310esque date, or JavaFX Duration. The latter is
>> designed mostly for millis to hours, but isn't using 310 either. And as
>> long as JavaFX aims to be backward-compatible with either its own older
>> versions or Java 5-7 it never will be. Theoretically some day it could use
>> the Duration class in java.time, but we'll see a lot of time literally pass
>> till this is going to happen... If JavaFX ever did, an API like 354 might
>> also consider using Duration or the underlying TemporalAmount****
>>
>> ** **
>>
>> Werner****
>>
>> ** **
>>
>> On Thu, Aug 8, 2013 at 11:55 AM, Stephen Colebourne <scolebourne@...>
>> wrote:****
>>
>> On 8 August 2013 06:35, Anatole Tresch <atsticks@...> wrote:
>> > when trying to implement regional validity of currencies in the RI I
>> > encounter a possible issue with our currency validity model, I think we
>> have
>> > to discuss. The point is that ISO, as well as CLDC sources all model the
>> > currencies validity in form of a local date (in the sense of 310), so
>> > without any timezone information. In our model, we currently have the
>> UTC
>> > from/to timestamps, which for all querying APIs may match well, and IMO
>> also
>> > make sense for exchange rates. But in case of the validity records for
>> > currencies, it makes it difficult to implement the SPI, since I have to
>> > convert each local date for each region/territory, where a currency is
>> > valid, to an UTC timestamp. In case of big countries with multiple
>> timezones
>> > this even leads to potential invalid data, since the validity record is
>> not
>> > constraint to a specified timezone. Additionally I think that for most
>> use
>> > cases local dates for currency validity is sufficient and also feel more
>> > natural, so using local dates would match the commonly used way to model
>> > this, and with UTC we add here unnecessary complexity.
>> >
>> > As a consequence this leads to another point: how we should model local
>> > dates without 310...****
>>
>> Ignoring the obvious response of just using JSR-310, you have various
>> choices:
>>
>> - use epoch-day, an int/long count of days where 0 is 1970-01-01
>> - use modified-julian-day, an int/long count of days where 0 is 1858-11-17
>> - write a ValidityDate class equivalent to LocalDate, which could
>> implement JSR-310 interfaces later
>>
>> Stephen****
>>
>> **
>>
>

Attachment: image001.gif
Description: GIF image

Attachment: image002.gif
Description: GIF image

Attachment: image003.gif
Description: GIF image

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image

Attachment: 322.gif
Description: GIF image



[JSR-354] Validity Dates for CurrencyValidity

Anatole Tresch 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

magesh.kasthuri 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Greg Bakos 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Anatole Tresch 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Stephen Colebourne 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Tresch Anatole (KGVA 55) 08/08/2013

[JSR-354] Re: Validity Dates for CurrencyValidity

Werner Keil 08/08/2013
 
 
Close
loading
Please Confirm
Close