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 15:49:45 +0200

In the *implementations*, a standalone RI of JSR 354 would still have to
refrain from something that only becomes integral part of SE 8, but similar
to LogStash, if it's worth the effort and increased size/complexity,
including e.g. JodaTime (the whole distro is 10MB[?] but the actual JSR only
around 560kb, so compared to the much more powerful ICU4J it's tiny[?]) why
not. That 310 "Backport" won't be reliable until the actual Java 8 content
is out, so if it's inside an implementation and does not affect the public
API method signatures, I'd probably go for JodaTime.

For the public signatures could we try to use only Calendar rather than
concrete instances like GregorianCalendar. Also long as arguments unless
there's a method that must return null in this form??

Cheers,
Werner

On Thu, Aug 8, 2013 at 3:40 PM, Tresch Anatole (KGVA 55) <
anatole.tresch@...> wrote:

> Hi Werner****
>
> ** **
>
> As mentioned in my first email ;-), I did never want to change anything
> for exchange rates or the validity query APIs.****
>
> Only for the currency validities returned and thus stored/managed within
> the SPI implementations…****
>
> ** **
>
> Cheers,****
>
> ** **
>
> 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 15:22
>
> *To:* jcurrency_mail@...
> *Subject:* [JSR-354] Re: Validity Dates for CurrencyValidity****
>
> ** **
>
> Lots of the new JSON/REST based new APIs you see everywhere in the Web do
> exactly that btw. Also the ones dealing with Money and Bitcoin****
>
> ** **
>
> The problem is, creating this just for validity and leaving conversion
> with 2 longs would make the API almost more confusing than if you went on
> embedding ICU4J here and baked JodaTime into the other one (in the absence
> of 310, that's not an option until Java 8 is both final and widely enough
> accepted)****
>
> ** **
>
> The validity may find "date" in the sense of Year/Month/Day sufficient,
> but exchange rates if not within milli- or nanoseconds at least change
> several times per day, so that requires a DateTime equivalent.****
>
> ** **
>
> Cheers,****
>
> Werner****
>
> On Thu, Aug 8, 2013 at 3:15 PM, Tresch Anatole (KGVA 55) <
> anatole.tresch@...> wrote:****
>
> If timestamps would be a good model for the use case here, I would not
> discuss it. If I design an SPI and I see that its implementation is
> cumbersome, I think the SPI must be discussed. Even if a *thousands* of
> time implementations would exist in the JDK, there is obviously no one,
> that really matches our use case here.****
>
> This is also the reason, why sometimes date are mapped to Strings, e.g. as
> “12011970”… (which I did and will not propose)…****
>
>  ****
>
> Cheers,****
>
>  ****
>
> 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 15:09****
>
>
> *To:* jcurrency_mail@...
> *Subject:* [JSR-354] Re: Validity Dates for CurrencyValidity****
>
>  ****
>
> Yes, but that only captures a UTC timestamp, what value does a wrapper
> interface have here? I'd stick to the long or Long for Beginning and End,
> otherwise we'd overengineer it for the scope of a Monetary API.****
>
>  ****
>
> There are so many frameworks out there, let's face it, more people in real
> business apps use ICU4J (not only Eclipse, a vast majority of Apache
> projects uses it, too, see Harmony, but it won't be the only one) JDK has
> millis almost everywhere, even JavaFX uses them internally (as a "delta"
> between start and end timestamp) while 310 has a combination of seconds and
> nanos (within the duration, otherwise you won't get so far with int)****
>
>  ****
>
>  ****
>
> On Thu, Aug 8, 2013 at 2:57 PM, Tresch Anatole (KGVA 55) <
> anatole.tresch@...> wrote:****
>
> Hi Werner****
>
>  ****
>
> Just to be precise****
>
> 1)      We talk about *LocalDate* not Duration****
>
> 2)      The discussion is API relevant (ext package).****
>
>  ****
>
> Cheers,****
>
>  ****
>
> 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 14:52****
>
>
> *To:* jcurrency_mail@...
> *Subject:* [JSR-354] Re: Validity Dates for CurrencyValidity****
>
>  ****
>
> 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: image008.gif
Description: GIF image

Attachment: image007.gif
Description: GIF image

Attachment: image009.gif
Description: GIF image

Attachment: image006.gif
Description: GIF image

Attachment: image005.gif
Description: GIF image

Attachment: 329.gif
Description: GIF image

Attachment: 322.gif
Description: GIF image



[JSR-354] Re: Validity Dates for CurrencyValidity

(continued)

[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