personnummer / java Goto Github PK

Description

To fully implement the v3.1 specification, the project needs to support interim numbers (see https://github.com/personnummer/meta#interim-number).

Breaking changes

As long as the options object keeps the default value of interim numbers as false, there should be no breaking changes.

Is it intended that the regex used to validate a personnummer should accept | as a separator besides + or -?

regexPattern = Pattern.compile("^(\\d{2})?(\\d{2})(\\d{2})(\\d{2})([-|+]?)?((?!000)\\d{3})(\\d?)$");

If not, then | should be removed from [-|+], since the [] regex notation is already an or by itself, and the | is not interpreted as an or-operation, but as the character |.

valid(long) returns false for valid personal numbers starting with 0:

valid(001224-4919L) - (long) returns false
valid("001224-4919") (String) returns true

Fixed in #17

Issue candidate for wontfix tag? 🙃

Description

If I pass in a Organization number it should be parsed OK as well.

Breaking changes

I suggest a new Factory for creating the PNR and ONR objects to not create breaking changes.

A Modest Proposal

Implementing some Java specific methods might be beneficial, such as:

1. Overriding equals()

2. Overriding hashCode()

3. Overriding toString() - perhaps returning the format()method?

4. Implementing Comparable<Personnummer> for sorting.

For 1 and 2 behaviour needs to specified.

Description

To implement v3.1 specification, this package needs to expose a getDate property which returns the number as a date (year, month, date) in a suitable structure.

Breaking changes

No breaking changes expected.

The line 136 has an else and check the day > 60 in case there is no allowance for coordinatio number as per SKV spec.
} else if(day > 60) { throw new PersonnummerException("Invalid personal identity number."); }

The check is not needed since there will be a check at line 150 where the day , month and year semantic will be checked from DateTimeFormatter

In Case you want to keep the else statement, it would be nice to check against day > 31 ( max day in a month )
Not sure why the day > 60 exist in the else statement.
Thanks
Alan

Hi guys,
This might be a bug. Using one of the ssn:s in your tests (701063-2391) and then prepending it with a '9' still returns true.
This test fails:
assertFalse(Personnummer.valid("9701063-2391"));

br Svante

Context

Personnummer.parse() does not throw PersonnummerException if you enter a Organisationnummer.

Expected outcome

Get a PersonnnummerException
Actual outcome

Got a Personnummer object. Only to fail once one calls toString().

Description

Minimal reproducible test case

    val invalidPin = "556748-7862"
    try {
        val pin = Personnummer.parse(invalidPin)
    } catch (e: Exception) {
        println("We got a error: $e")
    }
    println("Everything is fine")

If you however call toString() on the object you will get a DateTimeException

java.time.DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 67

First of all - stor tack for the library!

Would it be possible for you to publish it to Maven Central to avoid hassle of dealing with GitHub packages?

Travis build fails using Oracle JDK. Oracle has changed the licence for Oracle JDK.

The Oracle JDK License has changed for releases starting April 16, 2019.
The new Oracle Technology Network License Agreement for Oracle Java SE is substantially different from prior Oracle JDK licenses.

I suggest removing it entirely in favour of OpenJDK. OpenJDK is the reference implementation of Java, and is licensed under GPL v2 with classpath exception.

Reference links:
https://launchpad.net/~webupd8team/+archive/ubuntu/java
https://travis-ci.community/t/java-8-failing-download-failed-oracle-jdk-8-is-not-installed/1894

Context
If we are using test numbers that have a correct checksum but the last 4 digits start with 000 we cannot parse them.

Expected outcome
Parsable but some signal available that shows this is not real data

Actual outcome
Constructor fails

Description

I suggest that parse should work but valid() should fail - and there could be a valid(boolean allowZeros) method that wouldn't fail.

If this seems like a valid solution, I would be willing to code it.

Minimal reproducible test case

Personnummer.parse("187303140003");

Description

Breaking changes

Personnummer.format(true) doesn't work as described in the javadoc's, separator is omitted if longFormat==true

In the README under the section Validation it seems that the last two examples have misplaced separators, but the text imply that they are correct.

import dev.personnummer.*;

class Test 
{
  public void TestValidation() 
  {
    Personnummer.valid("191212121212");    // => True
    Personnummer.valid("12121+21212");     // => True
    Personnummer.valid("2012121-21212");   // => True
  }
}

The program disregards the - and + sign in personal numbers (personnummer). It is used for determining what century the person was born in. It gets changed from a dash - to a plus sign + when a person turns 100 years old.

For example:
19130401-2931 returns true
19130401+2931 returns true

Only the latter should return true.

References:
Personnummer och samordningsnummer (Skatteverket) - in Swedish

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update dependency org.json:json to v20240303

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository