Enthuware

In the above test all the weeks were automatically converted to days when printed. So has something changed in JVM, or the phrase in the book is not referring to the results?

Last line of the first paragraph under "Parsing a string to create a Period" heading.

p1Y2w means 1 year and 2 weeks.

You mean, "For example, P1Y10M3d means 1 year, 10 months, and 3 days, P1Y3D means 1 year and 3 days. p1Y2w means 1 year and 2 weeks"? It is correct. It is talking about what these specification strings imply. i.e. y is for years, d is for days, m is for months, and w is for weeks.

It is not talking about how the Period object gets printed. Should be made clear.

Ok. By the way, is there some reason that weeks get converted to days when printed? What if the print results had to show the weeks?

Thanks

The Javadoc says, "The supported units of a period are YEARS, MONTHS and DAYS." Only the API designers can answer why they decided not to support WEEKS as well. I don't remember coming across any reason for this.

If you want to print weeks, you need to get days and divide by 7. There is no getWeeks method in Period.

LocalDate uses ISO_DATE, LocalTime uses ISO_TIME

should be

LocalDate uses ISO_LOCAL_DATE, LocalTime uses ISO_LOCAL_TIME

?

(I accidentally discovered this while looking at the Example column for Predefined Formatters at https://docs.oracle.com/javase/8/docs/a ... atter.html)

Apparently, there may be differences? Does the exam expect us to know these differences?
Example:
ISO_LOCAL_DATE ISO Local Date '2011-12-03'
ISO_DATE ISO Date with or without offset '2011-12-03+01:00'; '2011-12-03')

Reference:
https://docs.oracle.com/javase/8/docs/a ... rSequence- https://docs.oracle.com/javase/8/docs/a ... rSequence-

You are right. It should be the "LOCAL" versions. Added to errata.
No, you are not expected to know about these differences in the exam.

Great to hear. One more thing, I was puzzled by this, but I think that possibly

Just like the no-args parse method, the toString method uses the ISO format for generating
the string.

should be

Just like the non-DateTimeFormatter arg parse method, the toString method uses the ISO format for generating
the string.

?

Correct!

is that correct?

LocalDate uses ISO_DATE, LocalTime uses ISO_TIME, and LocalDateTime uses ISO_LOCAL_DATE_TIME to parse the given string. Thus, for example, invoking LocalDate.parse("2018-02-14"); will produce the same result as invoking LocalDate.parse("2018-02-14", DateTimeFormatter.ISO DATE);

the first two use ISO_ but last use ISO_LOCAL??
why

hello again

this doesnt work
it gives : java.time.format.DateTimeParseException: Text 'Oct/23/19' could not be parsed at index 0

hum now it work after i changed "Oct" to "oct."

LocalDate ld = LocalDate.parse("oct./23/19", dtf);

this works now

it was a pdf error??

if i have exam should i say that Oct is false or true?

because pdf shows months like this: "Jan" "Feb" but my computer show like this "jan." "feb."

Which Java version are you using? I just tried this code on Java 21 as well as 17. LocalDate.parse("Oct/23/19", dtf); works fine on both and prints 2019-10-23.
Also, double check how you are creating dtf. It should be:
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("MMM/dd/yy");

In fact, oct. doesn't work.

ok i use java 21, maybe its my windows which is in french

anyway i will remember for OCA exam that Oct works

thanks for letting me know btw

Oh yes, right. Since it is a "local" date, the month value must be in format expected by the default locale of your program. Should be mentioned in the book.

thanks again

You said ISO_LOCAL_DATE is default like its general, but it's default only because we use LocalDate.parse()
If we use OffsetTime.parse() then default would be ISO_OFFSET_TIME

Also a lot of mention of ISO_DATE but it's only for Date class, and we should avoid this class from java.util since it became old

Sure. thank you for your feedback!