gmane.comp.java.jsr310.devel

New

2011-11-11T15:15:31

I am a developer from Nigeria. We could connect as i learn a lot on
this project. Thanks

RE: JSR 310: Date and Time API

2011-11-09T15:16:50

Hi,

Thanks for your reply. Please find my comments in CAPS below:-

Thanks,
JD

-----Original Message-----
From: Maarten Bodewes [mailto:maarten.bodewes< at >gmail.com]
Sent: Wednesday, November 09, 2011 2:53 AM
To: dev< at >jsr-310.java.net
Subject: Re: JSR 310: Date and Time API

Hi JC & Steven,

I think it depends on the use case which exceptions should be tested
for. Personally, I prefer to throw a IllegalArgumentException if a
null argument is encountered. Most of the time, I specify ", never
null" behind the JavaDoc of the argument, and list the
IllegalArgumentException in the JavaDoc (not in the interface). The
main reason is to mention the argument name in the exception though. A
NullPointerException could also do for obvious cases like this one,
especially since the given argument is not simply stored in a field
where it can cause problems later.
THAT IS PRECISELY WHY I WANTED A NULL-POINTER EXCEPTION HERE..I GUESS IT MUST BE ALREADY HERE BY NOW
OR I MIGHT BE LOOKING AT THE OLD COPY

Re: JSR 310: Date and Time API

Maarten Bodewes — 2011-11-08T21:23:03

Hi JC & Steven,

I think it depends on the use case which exceptions should be tested
for. Personally, I prefer to throw a IllegalArgumentException if a
null argument is encountered. Most of the time, I specify ", never
null" behind the JavaDoc of the argument, and list the
IllegalArgumentException in the JavaDoc (not in the interface). The
main reason is to mention the argument name in the exception though. A
NullPointerException could also do for obvious cases like this one,
especially since the given argument is not simply stored in a field
where it can cause problems later.

Obviously, I don't type this all out, I've got an Eclipse template
that performs the test on an argument, and throws the exception, with
the name neatly filled in. Of course, it would still be better if we
could specify something like < at >NotNull or even < at >NullAllowed and the
test would take place automatically at compile time if possible *and*
runtime if required. Maybe Java 9?

Catching "Exception" or "RuntimeException" is something yo

RE: JSR 310: Date and Time API

2011-11-08T11:49:19

Hi,

I have noted a few points on which your expert opinion is highly appreciated:-
URL:- http://threeten.svn.sourceforge.net/viewvc/threeten/trunk/threeten/src/main/java/javax/time/Duration.java?revision=1443

1) There are functions such as shown below public Duration minusNanos(long nanosToSubtract) {

 Which do not have a check for NaN or a divide by zero error. Though this could be run-time, there are high chances that an absence of a throws or a try-catch can cause issues. We might want to have a look at it.

2) I was wondering if we could make our Date Conversion functions smart enough to retain and convert dates ( based on the flag parameter).

I propose that we add a function parameter in any of our date conversion functions..say smartConvert . If this is set to true , we will convert the date
Or obtain the date processing results in such a way that we get the most accurate of results.

For e.g. say we need to find the day from the given date. Now, say the date is long but the conversion is taken fro

RE: JSR 310: Date and Time API

2011-11-08T06:53:39

Hello,

1) I
I was going through the code on the URL:-

http://java.net/projects/jsr-310/sources/svn/content/trunk/jsr-310-ri/src-openjdk/main/java/java/util/Calendar.java?rev=1339

Why are the methods not having a Null-Pointer Exception or even just a general exception handler? I think this might cause issues in some of these methods in this project.


/**
     * Sets the instant represented by this <code>Calendar</code> to be the same as
     * the provided <code>Instant</code>.
     * <p>
     * An {< at >link InstantProvider} is a simple interface that is implemented by
     * numerous date-time classes.  It provides a mechanism to convert those
     * objects to an instance of <code>Instant</code> which is then used to
     * set the time of this <code>Calendar</code>.
     * <p>
     * <code>Instant</code> uses a precision of nanoseconds, whereas
     * <code>Calendar</code> uses a precision of milliseconds.  The conversion will
     * drop any excess precision information as though the amount in nanosecon

Discussion started on the ThreeTen list!

Stephen Colebourne — 2011-01-07T12:02:07

All,
Discussion has now staretd on the threeten-develop list. Please sign
up to that list to follow future discussion.
https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=2292

Mailing list signup:
https://sourceforge.net/mail/?group_id=386712
ThreeTen principles: "This project works on trust and respect for the
public good. Contributions to project discussion (including, but not
limited to, mailing lists and wiki edits) is publicly available
information which may be used by anyone in any way forever. "

thanks
Stephen

Re: Announcement: Moving JSR-310 to ThreeTen

Stephen Colebourne — 2010-12-30T22:51:36

Because other projects I lead are at sf, not GitHub.
Stephen

On 30 December 2010 22:43, Yishai Hornbacher <yh-eyaujN1mccpBDgjK7y7TUQ< at >public.gmane.org> wrote:

RE: Announcement: Moving JSR-310 to ThreeTen

Yishai Hornbacher — 2010-12-30T22:43:31

I'm not advocating for it, but I am curious why you chose sourceforge and not github? I always find that when I ask these kinds of questions I learn things, so I thought I would ask in this case as well.

-----Original Message-----
From: jodastephen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org [mailto:jodastephen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org] On Behalf Of Stephen Colebourne
Sent: Thursday, December 30, 2010 6:13 AM
To: dev
Subject: [jsr-310] Announcement: Moving JSR-310 to ThreeTen

All,
With the impending move from java.net to Kenai, and the recent JCP issues, I took to opportunity to re-evaluate the status of JSR-310.

The full details are on my blog:
http://www.jroller.com/scolebourne/entry/what_about_jsr_310

In summary, JSR-310 is continuing, but treating the JSR process as a necessary tool to reach Java SE 8 rather than the prime focus.

As part of this, I have moved the project from java.net to sourceforge. I have also taken the opportunity to separate more clearly the project and the JSR, creat

Announcement: Moving JSR-310 to ThreeTen

Stephen Colebourne — 2010-12-30T11:12:52

All,
With the impending move from java.net to Kenai, and the recent JCP
issues, I took to opportunity to re-evaluate the status of JSR-310.

The full details are on my blog:
http://www.jroller.com/scolebourne/entry/what_about_jsr_310

In summary, JSR-310 is continuing, but treating the JSR process as a
necessary tool to reach Java SE 8 rather than the prime focus.

As part of this, I have moved the project from java.net to
sourceforge. I have also taken the opportunity to separate more
clearly the project and the JSR, creating the ThreeTen project. For
the most part this has no impact on how the project is run, but it
does allow us to create a specification separate from the JCP should
we desire it.

Thus, going forward, the ThreeTen project is the reference
implementation of JSR-310:
https://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen

All discussion about the ThreeTen project, and JSR-310 will occur on
the develop mailing list at sourceforge.

THIS LIST AND PROJECT WILL SOON BE TERMINA

Re: Period.totalXxx() behavior inconsistence

Stephen Colebourne — 2010-12-22T14:37:05

Agreed. Any miuse of the API needs looking at. Its the most valuable
form of feedback.

Stephen

Re: Period.totalXxx() behavior inconsistence

Maarten Bodewes — 2010-12-22T14:09:55

I would personally agree that there is at least a naming problem here.
Reading the code and seeing the answer returned is rather frightening.
I can imagine countless devs first calling totalMonths(), seeing that
it returns correctly, only to find out that the next call fails rather
spectacularly.

Regards,
Maarten

Re: Period.totalXxx() behavior inconsistence

Yago Méndez Vidal — 2010-12-22T13:41:16

About the way to calculate the days, my apologies, just noticed the 
Period.daysBetween(DateProvider, DateProvider) method, had to had checked 
the API better before.
Anyway, the main question about the total methods is still up.

Sorry and thanks in advance,
Yago

-----Mensaje original----- 
From: Stephen Colebourne
Sent: Wednesday, December 22, 2010 12:45 PM
To: dev-tnrT5kQ3EfwiovNZN9pwmeTW4wlIGRCZ< at >public.gmane.org
Cc: dsmania-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org
Subject: Re: [jsr-310] Period.totalXxx() behavior inconsistence

Hi,
The totalDays() method only calculates the total number of days
totalling the hours, minutes, seconds and nanos.

There is no way to calculate the total including the months and years
without a reference date to calculate from, as months and years vary
in length.

Stephen


On 22 December 2010 11:39, Yago Méndez Vidal <dsmania-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:

Re: Period.totalXxx() behavior inconsistence

Yago Méndez Vidal — 2010-12-22T13:17:16

Hi,
While I understand that point, if you notice the code there are 2 exact 
dates for the period, so the expected bevavior from my point of view as a 
developer is that the "total" methods would return the total amount of those 
units I can find in that period.

Thinking a bit and reading the code in Period... I see that total methods 
work in 2 ranges: years+months and days+hours+... because of that point you 
commented.

I find that calling them the same way while day and lower units ignore years 
and months can drive to some missunderstanding. Don't know if a good idea 
would be renaming the methods to .totalXxxIgnoringYearMonth() or not 
allowing to use total methods that calculate total days and lower when there 
are months and years specified with an exception... or maybe I'm looking for 
a solution for something that is not a real problem. I'm just a bit 
confused.

The thing is that I know that it's 368 days until Christmas 2011 and using 
Period I find no intuitive way to code it.

Not that I'm say

Re: Period.totalXxx() behavior inconsistence

Stephen Colebourne — 2010-12-22T11:45:03

Hi,
The totalDays() method only calculates the total number of days
totalling the hours, minutes, seconds and nanos.

There is no way to calculate the total including the months and years
without a reference date to calculate from, as months and years vary
in length.

Stephen


On 22 December 2010 11:39, Yago Méndez Vidal <dsmania-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org> wrote:

Period.totalXxx() behavior inconsistence

Yago Méndez Vidal — 2010-12-22T11:39:51

I found some inconsistence on the totalXxx() methods of Period class. While 
some methods return the actual total amount of units of that period, others 
return the specidied amount.

If you try to execute this code:

public class PeriodGetXxxTest {

    public static void main(String... args) {
        LocalDate christmas2010 = LocalDate.of(2010, 12, 25);
        LocalDate myBirthDate = LocalDate.of(1980, 11, 16);

        Period timeBetweenBirthAndMy31thChristmas = 
Period.between(myBirthDate, christmas2010);
        System.out.println(timeBetweenBirthAndMy31thChristmas);
        System.out.println(timeBetweenBirthAndMy31thChristmas.totalMonths());
        System.out.println(timeBetweenBirthAndMy31thChristmas.totalDaysWith24HourDays());
    }

}

... in the console you can read:

P30Y1M9D
361
9

... which makes inconsistence between the two .totalXxx() methods, where one 
actually returns the total amount of months, while the other returns the 
specified amount of days .

PS: I didn't dare to say it's a bu

Re: adding UTCDateTime class

Stephen Colebourne — 2010-12-14T16:43:01

Correct.

Well, since I'd implement it as a wrapper around LocalDateTime, it
would in fact be larger. I'd predict the size to be 4 bytes less than
ODT as the only saving is the 4 byte reference to the offset.

I expect that the database integration will be significantly improved
as part of the integration into the JDK. This should avoid the common
issues around the wrong offset. With those changes, there should be no
need to go as far as running the JVM in UTC to get accurate dates and
times. As such, the need for a dedicated UTC date-time is reduced
again.

Unfortunately, its already the case that the API is complex with 8 key
types to understand. Adding another that duplicates the functionality
of the others isn't something I can support. Of course, since the API
is extensible, its perfectly possible to write such a class and have
it integrate with the rest of the API quite nicely.

Stephen

Re: adding UTCDateTime class

David Momper — 2010-12-09T06:30:53

Thanks for the reply, Stephen. I know that this class is not
necessary, but I think it would be a very valuable convenience class.
I'll try to address some of your concerns.


That is correct, I'm referring to UTC in the lenient sense that
basically means zero time zone offset, leap seconds ignored. If this
class were added, a different name would be needed.


If an object is known to always be UTC, then the offset field in
OffsetDateTime would be redundant, because the value would always be
zero (unless I'm missing something). If the ZoneOffset and TimeZone
are known to be ZoneOffset.UTC and TimeZone.UTC, they can be
referenced statically any time they are needed. The class could
provide all the functionality of ZonedDateTime, while only storing
LocalDate and LocalTime. I threw together some rough code to check the
size of objects on the heap:

java.util.Date = 24 bytes (120 bytes after initializing cdate)
GregorianCalendar = 400 bytes (?!)
Instant = 24 bytes
LocalDateTime = 56 bytes
OffsetDateTime = 72 byt

Re: adding UTCDateTime class

Stephen Colebourne — 2010-12-08T15:16:59

Hi,
I guess I'm unclear as to why we'd need this class.

OffsetDateTime should be used in preference to ZonedDateTime when
dealing with a fixed offset, such as UTC. Creating an instance is
pretty easy, it has better performance than ZDT and smaller memory
size. A UTC version of ODT would simly save 4 bytes, gain marginal
performance (simply avoiding add/subtract the offset) and be
marginally easier to create. It would have the downside of being
another class in the system to explain and to have methods to convert
to and from.

In addition to ODT, there is Instant. Instant is an instant in time
suitable for timestamps where the main intention is not to output as a
human formatted date-time. When an instant is printed, UTC is used.

With these two classes, a UTCDateTime would simply be adding an
additional type to express the same concept. There have already been
some doubts as to whether having these two separately is justified, so
I'd argue against adding a third representation of the same thing.

Finally, y

adding UTCDateTime class

David Momper — 2010-12-08T01:53:43

I'm writing to investigate the possibility of adding a UTCDateTime
class to JSR-310 for a DateTime that is defined as UTC.

I write Java for use with databases, and I deal almost exclusively
with DateTime values stored and retrieved in UTC. I believe that UTC
DateTimes are a special case that are used so frequently that a
special class is justifiable.

A UTCDateTime class would provide the same functionality as a
ZonedDateTime, but it would offer some benefits:
* enforce that a DateTime field is zoned UTC
* improvements in performance
* smaller size in memory

If UTCDateTime can be included, I will be happy to contribute code for
it. I welcome any feedback on this idea.

Thanks,
David Momper

Version 0.6.3

Stephen Colebourne — 2010-12-02T19:23:53

I've cut a version of 310 to mark our current position. The change log
since 0.6.2 is as follows (yes, its a little cryptic...):

Stephen

- nanoOfDay rule / epochDays rule
- Use public factories for ZOT and ZOTR rather than protected methods in ZRules
- Make CalendricalRule.compare less lenient
- Add TAIInstant.parse()
- Print/parse two digit years
- Add Period.toEstimatedDuration()
- Rename PeriodFields.normalize() to normalizeTo()
- Add PeriodFields.normalize()
- Add Period.of(Duration)
- Make LocalDate.plus(PeriodProvider)/minus(PeriodProvider) strict
- Remove DatePeriod, adding methods to Period
- Add Period.withDateFieldsOnly()/withTimeFieldsOnly()
- Add Period.ofDateFields()/ofTimeFields()
- Rename Period.ofYearsMonthsDays() to ofDateFields()
- Rename Period.ofHoursMinutesSeconds() to ofTimeFields()
- LocalDateTime/LocalTime/Year/YearMonth.plus(PeriodProvider) have
correct algorithm
- ZoneOffset period factory
- ZDT int factories
- YearMonth.with(Year)
- LocalTime plus/minus shouldn't throw Arithmetic

Status 2010-12-02

Stephen Colebourne — 2010-12-02T16:44:38

This is a status update of tasks on the TODO list. Clearly it will
take a while to work through these issues, but that is what is
necessary to release.

If there are any concerns on specific items (or other things not
listed), please start a new thread.

Stephen


Status of JSR-310, 2010-12-02
=============================

The core API classes remain relatively stable, although non core
methods continue to change.

The following items are on the TODO list:

- What to do with MathUtils?
This is a class of code that is not specific to 310, but is required.
Simply adding the code to java.util.Math is insufficient, and 310
needs to run on Java 6 and maybe 5.

- Instant parse/toString
The toString/parse methods need implementing.
They cannot just reuse the formatting code, as they cover a greater
range of numbers.

- UTC leap second rules
The UTC leap second rules are in a manually edited file.
These should be moved to a better format and location.
The probably should be obtained from the TZDB rather than a file