ethlo / itu Goto Github PK

v1.7.2 defines an automatic module name

$ jarviz module name --gav com.ethlo.time:itu:1.7.0
subject: itu-1.7.0.jar
name: itu
source: filename
automatic: true
valid: true

$ jarviz module descriptor --gav com.ethlo.time:itu:1.7.0
subject: itu-1.7.0.jar
name: itu
version: 1.7.0
open: false
automatic: true
requires:
  java.base mandated
contains:
  com.ethlo.time
  com.ethlo.time.internal

$ jarviz bytecode show --gav com.ethlo.time:itu:1.7.0
subject: itu-1.7.0.jar
Unversioned classes. Bytecode version: 52 (Java 8) total: 18

I'd be great if the library supplied a full Java module descriptor. It's possible to keep bytecode baseline compatible with Java 8 while providing a full module descriptor thanks to ModiTect. This will help modular projects that consume this library, specifically those that create custom Java Runtimes with jlink, as the latter does not support automatic modules but explicit modules. If interested I can send a PR to make it happen.

Greetings,
I am currently trying to use JSON-Schema-Validator in our project that uses OSGI. JSON-Schema-Validator is already OSGI-ready, but it has since started using your ITU as a dependency, which prevents the validator from working in OSGI projects.

Would you be so kind to adapt ITU to an OSGI-bundle? The process should be fairly straightforward and would only require you to add a few lines of text to the pom.xml file. These changes wouldn't affect most people, but would help those using OSGI immensly.

You can reference JSON-Schema-Validator's POM.xml. I've highlighted the required lines for the Maven plugin here. Additionally this single line to set the packaging as a 'bundle'. ITU will be fully OSGI compliant with the Maven plugin and the packaging declaration added.

A more detailed guide can be found here.

If you'd like, I can make these changes myself as a PR for you to check out.

According to https://datatracker.ietf.org/doc/html/rfc3339#section-5.6
the fraction should have at least one digit.
But ITU considers e.g. "2017-02-21T15:27:39.+00:00" as valid.
I can provide a pull request if you like.
Maybe together with CorrectnessTest#testValid and CorrectnessTest#testInValid be refactored to @ParameterizedTest?

2016-04-27T11:30:24.952123456 and 2016-04-27T11:30:24.952123 are valid formats but throw expections

Caused by: java.time.DateTimeException: Invalid timezone offset: 952123456
at com.ethlo.time.FastInternetDateTimeUtil.parseTz(FastInternetDateTimeUtil.java:99)
at com.ethlo.time.FastInternetDateTimeUtil.seconds(FastInternetDateTimeUtil.java:383)
at com.ethlo.time.FastInternetDateTimeUtil.doParseLenient(FastInternetDateTimeUtil.java:331)
at com.ethlo.time.FastInternetDateTimeUtil.parseDateTime(FastInternetDateTimeUtil.java:53)

ITU.parse should be ITU.parseLenient in the readme

According to the RFC the separator between date and time may be T, t or space. The UTC time zone character may be Z or z.

Currently, the parser will accept any leap second at either end of June or the end of December. Improve this by using a list of known leap seconds dates in the past and keep the current rule for date-times after the last known leap-second year/date. This will avoid breaking the parsing of valid leap second due to not having the very last updated list of leap-seconds.

This is a regression as previously in v1.8.0 the invalid date time 1963-06-19T08:30:06.28123+01:00Z that has a trailing Z was being rejected but is now being accepted.

This change was introduced at

• 2618dec#diff-ee3f71d4d91b6b346de3994a501391bbebae44f408bedd3e3a5f1a01c5f6aa4dR165

package com.ethlo.time;

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

public class IssueTest {
	@Test
	void shouldNotAllowTrailingZ() {
		Assertions.assertThrows(Exception.class, () -> ITU.parseDateTime("1963-06-19T08:30:06.28123+01:00Z"));
	}
}

Please, look https://tools.ietf.org/html/rfc3339 examples:

1990-12-31T23:59:60Z - This represents the leap second inserted at the end of 1990.
1990-12-31T15:59:60-08:00 - This represents the same leap second in Pacific Standard Time, 8 hours behind UTC.

ITU cannot parse these date-times.

RFC3339 documentation says:

The grammar element time-second may have the value "60" at the end of
months in which a leap second occurs -- to date: June (XXXX-06-
30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for
a table of leap seconds. It is also possible for a leap second to be
subtracted, at which times the maximum value of time-second is "58".
At all other times the maximum value of time-second is "59".
Further, in time zones other than "Z", the leap second point is
shifted by the zone offset (so it happens at the same instant around
the globe).