You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## In this PR:
* Modify publicly exposed methods to offer a `java.time` alternative
(suffixed with `Duration`). These methods will now hold the actual
implementation, whereas the old signatures will encapsulate the new
ones. Example: `retryDelay(org.threeten.bp.Duration)` encapsulates
`retryDelayDuration(java.time.Duration)`
## Notes
### _CLIRR_
```
[ERROR] 7012: com.google.cloud.testing.BaseEmulatorHelper$EmulatorRunner: Method 'public int waitForDuration(java.time.Duration)' has been added to an interface
```
This new interface method was added. However, we ignore this change
alert because the method has a `default` implementation.
### Addressing a behavior change in `Timestamp`
#### Problem
When using java.time functions, parsing a datetime string with offset
produces a wrong time object (offset is not added to the effective epoch
seconds).
#### Context
Full context in
https://github.com/googleapis/sdk-platform-java/pull/3330/files#r1828424787adoptium/jdk@c6d209b
was introduced as a fix (in Java 9) meant for [this
issue](https://bugs.openjdk.org/browse/JDK-8066982).
In java 8, this means that the offset value is stored separately in a
variable that is not respected by the parsing functions before this fix.
The workaround is to use `appendZoneOrOffsetId()`, which stores the
offset value in the `zone` variable of a parsing context, which is
[respected as of java
8](https://github.com/adoptium/jdk8u/blob/31b88042fba46e87fba83e8bfd43ae0ecb5a9afd/jdk/src/share/classes/java/time/format/Parsed.java#L589-L591).
Additionally, under the consideration of this having unwanted side
effects, we expanded the test suite to test for more edge and normal
cases using an offset string. We also
[searched](https://bugs.openjdk.org/browse/JDK-8202948?jql=affectedVersion%20%3D%20%228%22%20AND%20text%20~%20%22offset%22)
the JDK's issue tracking database and found somewhat similar issues with
parsing and offsets but no workaround that addressed our specific
situation. This is also cause of no backports of the
[fix](adoptium/jdk@c6d209b)
for Java 9 into Java 8.
#### Outcome
The behavior is kept the same as stated by our tests and downstream
checks
0 commit comments