Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] - Födelsetid support from Arbetsgivardeklaration (ruta 222) #60

Closed
Chuuone opened this issue Nov 28, 2024 · 5 comments
Closed

Comments

@Chuuone
Copy link

Chuuone commented Nov 28, 2024

Description

Firstly, thank you for implementing this collection of libraries!

Secondly, i am not sure if this feature is in the scope of this library but i wanted to put it forward anyway.

The proposed feature would support the YYMMDDnnn format for "födelsetid" supplied in Arbetsgivardeklaration. In short it is a "company-level" personnummer that the employer assigns temporarily to their employees while they lack a personnummer or sammordningsnummer.

Ruta 222
https://www.skatteverket.se/foretag/skatterochavdrag/kontrolluppgifter/kontrolluppgiftomvissalonerarvodensamtersattningfranpensionsochforsakringsutbetalaremedfleraku10ku19.4.96cca41179bad4b1aaa1dc.html

Breaking changes

The regexp would need adjusting.
Not luhn checkable.
Not gender checkable.

@bombsimon
Copy link
Member

bombsimon commented Dec 1, 2024

This is actually how some of the implementations I've done works. Basically as long as it conforms to the regex with a valid date an object is created. Calling valid() will fail, but if you got the object you know it's a valid date + 3 digits. Examples are Perl, gelam, Clojure and Rust.

At a quick glance it seems like other implementations doesn't do this, e.g. the Ruby implementation fails since the luhn validation is done in the constructor.

Do you think this is a reasonable approach to work with, i.e. if you can construct the object, it's a valid date with 3 digits? Did you find any project where you can get an object back even though it's not a valid date? Did you find any project where you passed a valid date and 3 digits but still didn't get an object back except the Ruby one I linked?

There will still be special cases for this, not the least for non-oop languages or languages without structs, e.g. the bash implementation but I think in most cases just relying on the regex and converting to a date object is what you're looking for.

@Chuuone
Copy link
Author

Chuuone commented Dec 1, 2024

Using PHP myself and i get an exception if the string doesn't conform to the options. I cant speak for any of the other projects as i dont use/havent tried them. I definitely think there should be another option that decides if YYMMDDnnn is valid or not. It makes the whole thing more transparent.

It is convenient your implementation "quietly" supports födelsetid.

Not familiar with those languages but it seems like they don't throw when something is invalid?

PHP does and it forces me to use try/catch block or write code that unnecessarily initializes the same object twice, but that stuff is all preference.

@bombsimon
Copy link
Member

Yeah makes sense, I can see how it't not convenient in a lot of cases.

I think avoiding validate luhn in any form of constructor and adding a complementary validation function to the spec is the proper way to go - if it would be added to the spec.

i am not sure if this feature is in the scope of this library

I think this is the real question to answer and for me personally I'd lean towards it being out of scope but I can't speak for everyone. Mainly because losing meaning of the gender methods and not utilizing key thing in the libraries which is the luhn check. I also don't know what a good way to determine if it is a födelsetid or not since it will look identical to a personnummer until the luhn check fails. At least for those packages that support creating personnummer without the control digit which all of the ones mentioned above does. (The idea was to be able to generate a valid personnummer by calculating the last control digit).

Also lastly for PHP, given that things like checkdate is in stdlib I think it's even easier to just validate the string (preg_match) and pass the first bits to checkdate so given the amount needed to validate this the need for a library seems less I think.

I'm thinking something like this (not that you asked for input on how to do it, but just to visualize the amount of code needed):

function validate(string $input): bool {
    if (!preg_match('/^(\d{6})\d{3}$/', $input, $matches)) {
        return false;
    }

    [$year, $month, $day] = sscanf($matches[1], '%2d%2d%2d');
    $year = $year < 25 ? 2000 + $year : 1900 + $year;

    return checkdate($month, $day, $year);
}

I'm leaving final decisions to @frozzare and @Johannestegner

@Chuuone
Copy link
Author

Chuuone commented Dec 2, 2024

When i think of a "Swedish social security number" library, i think of a library that understands and has full coverage of its variants. I can see why it might feel out of scope because it doesn't support gender or can be luhn checked, but to me that is just a variant with limited features and those "extras" are a convenient feature available with the other variants.

In regards to the code itself its pretty straight forward as you say. However in my case i need to support 3 formats and recognize them/allow on the fly between person, sammordning and födelsetid. I will likely run a fork of the PHP version tweaking what we discussed.

@Johannestegner
Copy link
Member

Hi there!

We have had a discussion in the core team and we all feel that this might be out of scope for the functionality of the package.
The idea of the package is to support the most common types of numbers (that is, personnummer, samordningsnummer and reservnummer), seeing those are the numbers that exist to "identify" a person.
There are various other numbers that we could support other than those, but if we do, it would make the package a lot bigger and much less easy to maintain.

So for now, we have decided not to support Födelsetid, but might reconsider in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants