On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato wrote:
> Clarifying the explanation for `TemporalUnit.between()`. There is already an
> example for the `HOURS` case where the minutes are not enough to make a full
> hour. Explaining how smaller units contribute to determining the whole
> number, al
On Mon, 3 Feb 2025 13:07:54 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/time/temporal/TemporalAccessor.java line
>> 327:
>>
>>> 325: * @return the year, from MIN_YEAR to MAX_YEAR
>>> 326: */
>>> 327: default int getYear() {
>>
>> The whole point of `TemporalAccess
On Fri, 31 Jan 2025 10:29:53 GMT, Shaojin Wen wrote:
> By using the Class File API to dynamically generate a CompositePrinterParser,
> and defining DateTimePrinterParser[] printerParsers as a specific field, C2
> can do TypeProfile optimization.
>
> Since the CompositePrinterParser is generate
On Tue, 3 Dec 2024 at 18:37, Louis Wasserman wrote:
> To add some more data, from taking a sample, at least a third of usages in
> Google's codebase were using it incorrectly in the way we've described.
I just checked, and only a few days ago I made this error (in a test
case, where it is less n
On Mon, 16 Sep 2024 19:30:56 GMT, Naoto Sato wrote:
>> make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java line 308:
>>
>>> 306: if (off < tokens.length) {
>>> 307: String dayRule = tokens[off++];
>>> 308: if (dayRule.regionMatches(true, 0
On Tue, 10 Sep 2024 22:42:37 GMT, Naoto Sato wrote:
>> This is a follow on fix to
>> [JDK-8339644](https://bugs.openjdk.org/browse/JDK-8339644). It turned out
>> that TZ data files allow abbreviation of keywords, such as "ZO" for "Zone."
>> Same fix, i.e, replacing `startsWith()` with `regionM
dd JavaTimeAccess SharedSecrets
> - Merge remote-tracking branch 'upstream/master' into
> optim_instant_fmt_202407
> - breaking out the printNano methods
> - copyright
> - Update
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>
&
On Sun, 11 Aug 2024 at 17:19, Alan Bateman wrote:
> Package.getPackage is deprecated a long time, I don't think we've seen too
> many complaints. Nowadays it's probably not too useful except to get to
> package annotations (everything else in that API dates from JDK 1.2 and the
> since removed
I make use of Package.getPackage in Joda-Convert but the method has
now been deprecated. I'd like to update my code, but AFAICT the
suggested alternative does not work.
The Joda-Convert code allows a user to convert a Package object to a
String, and back again. Reading the deprecation, I'm aware t
On Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen wrote:
> Similar to PR #20321, this improves performance by providing a method that
> passes in a StringBuilder to avoid unnecessary object allocation.
Change looks fine, but is it actually faster?
-
Marked as reviewed by scolebourne (
t incrementally with one additional
> commit since the last revision:
>
> Update
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>
> Co-authored-by: Stephen Colebourne
A more productive direction might be to move `LocalDate.formatTo` and
`Local
On Sun, 28 Jul 2024 15:52:03 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
On Fri, 19 Jul 2024 09:52:50 GMT, Andrey Turbanov wrote:
> A few methods in `java.time.chrono.ChronoLocalDateImpl` are unused and could
> be removed:
> 1. plusWeeks(long)
> 2. minusYears(long)
> 3. minusMonths(long)
> 4. minusWeeks(long)
> 5. minusDays(long)
>
> Tested `test/jdk/java/time` on L
On Fri, 26 Jul 2024 15:32:18 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> line 3818:
>>
>>> 3816: }
>>> 3817: // add fraction
>>> 3818: if (fractionalDigits > 0) {
>>
>> This breaks the logic. `frac
On Fri, 26 Jul 2024 15:44:59 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
On Fri, 26 Jul 2024 14:20:07 GMT, Shaojin Wen wrote:
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote:
>> The current LocalDateTime.toString implementation concatenates the toString
>> results of date and time, which can be passed to StringBuilder to reduce
>> additional object allocation and improve performance.
>
> Shaojin Wen has updated th
There are a variety of ways that a range of the timeline can be defined.
And some would argue that Java should have a general purpose Range class to
cover all Comparable classes rather than a few specific ones for Java time.
Ultimately, Java time chose to avoid the issues by not addressing the
des
On Mon, 3 Jun 2024 at 22:25, Kurt Alfred Kluever wrote:
> It feels a bit strange that you can't pass an `InstantSource` to
> `Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a
> "useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to
> propose one of the foll
Durations is an affine space
>> >>> <https://en.wikipedia.org/wiki/Affine_space#Definition>, with
>> >>> instants the points and durations the vectors. (An affine space is
>> >>> a vector space without a distinguished origin, which of cours
On Thu, 2 May 2024 at 15:58, Kurt Alfred Kluever wrote:
> instant − instant = duration // what we're discussing
> instant + duration = instant // satisfied by instant.plus(duration)
> instant - duration = instant // satisfied by instant.minus(duration)
> duration + duration = duration // satisfied
On Mon, 29 Apr 2024 21:32:16 GMT, Naoto Sato wrote:
>> A new method on Instant to return the duration `until` another Instant is
>> suggested per the following discussion thread:
>>
>> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html
>>
>> A CSR has also been drafted.
>
java.time.* already has the `until(ChronoLocalDate)` method on
LocalDate. It would be reasonable to add a similar method to various
other classes. This potentially gives you
Duration dur = start.until(end)
I'm wary of adding the opposite (given until() is already there). I'm
particularly wary of
On Thu, 27 Jul 2023 06:46:46 GMT, John Jiang wrote:
> if (i < savingsInstantTransitions.length) {
> // javazic writes the last GMT offset into index 0!
> if (i < savingsInstantTransitions.length) {
> offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
> nOffse
On Thu, 27 Jul 2023 11:01:23 GMT, Pavel Rappo wrote:
>> if (i < savingsInstantTransitions.length) {
>> // javazic writes the last GMT offset into index 0!
>> if (i < savingsInstantTransitions.length) {
>> offsets[0] = standardOffsets[standardOffsets.length - 1] * 1000;
>>
On Fri, 21 Jul 2023 15:59:42 GMT, Roger Riggs wrote:
>> In java.time packages, clarify timeline order javadoc to mention "before"
>> and "after" in the value of the `compareTo` method return values.
>> Add javadoc @see tags to isBefore and isAfter methods
>>
>> Replace use of "negative" and po
On Tue, 11 Jul 2023 17:54:23 GMT, Roger Riggs wrote:
>> In java.time packages, clarify timeline order javadoc to mention "before"
>> and "after" in the value of the `compareTo` method return values.
>> Add javadoc @see tags to isBefore and isAfter methods
>>
>> Replace use of "negative" and po
On Fri, 16 Jun 2023 22:12:43 GMT, Roger Riggs wrote:
>> In java.time packages, clarify timeline order javadoc to mention "before"
>> and "after" in the value of the `compareTo` method return values.
>> Add javadoc @see tags to isBefore and isAfter methods
>>
>> Replace use of "negative" and po
On Fri, 5 May 2023 21:28:25 GMT, Roger Riggs wrote:
> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases
> did not correctly borrow or carry from the nanos to the seconds when
> computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
> The errant computation was introdu
This looks like a bug from the description below, although it is surprising
that it isn't caught by tests.
Stephen
On Wed, 3 May 2023, 21:47 SHARPE, Stuart (Commercial & Institutional CDIO),
wrote:
> Hi Roger,
>
> Thanks for the reply.
>
> I must admit I am struggling to understand your explanat
On Wed, 1 Feb 2023 20:19:20 GMT, cheenar wrote:
>> test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java line 141:
>>
>>> 139: @Test(dataProvider="rules")
>>> 140: public void test_isValidOffset_LDT_ZO(ZoneRules test, ZoneOffset
>>> expectedOffset) {
>>> 141: if (expected
31 matches
Mail list logo
