[FEATURE] - More ways to format a personnummer

[PumpedSardines]

Description

Currently this package only supports two ways to format a personnummer default: 830621-9299 and long: 198306219299. In my experience, there are generally four ways that a personnummer is usually structured:

short: 8306219299
long: 198306219299
separated short: 830621-9299
separated long: 19830621-9299

My proposal is to implement a way to format personnummer in more ways that two. But more importantly make the package able to support more that two formats without breaking.

Implementation

Instead of passing a boolean to the format function you pass a format type. This should ideally be created with a class which can be extended and make it possible to create more formats down the line.

Example implementation:

abstract class FormatType {
    abstract format(personnummer: Personnummer): string;
}

class FormatSmall extends FormatType {
    format(personnummer: Personnummer) {
        const { year, month, day, num, check } = personnummer;
        return `${year}${month}${day}${num}${check}`;
   }
}

class Personnummer {
   ...
    
    format(format: FormatType) {
        return format.format(this);
    }

    // We could also include functions for every format that is included in this library
    formatSmall() {
        return this.format(new FormatSmall());
    }

   ...
}

And alternative implementation is using enums / strings with different format types

enum FormatType {
    Small,
    Long
}

class Personnummer {
   ...
    
    format(format: FormatType) {
        switch(format) {
            case FormatType.Small:
                return "formatted personnummer";
        }
    }

   ...
}

This solution is less extendable and doesn't allow people to implement their own format functions. However this solution is simpler and is easier to implement in language such as Bash and Haskell (I don't have very much experience in any of those languages so I'm not if the first implementation is even possible in them).

Breaking changes

Depending on how this is implemented this could be breaking. Ideally the old boolean system should be removed completely. However the old function could still be accessible either trough overloads or joint types. I would advocate to remove the old system completely since this package is rather small and it shouldn't be to complicated to migrate to the new function if you decide to update to the newest version.

[Johannestegner]

Hi!

Thank you for the feature request. This is something we have been discussing to introduce as a new feature in the next API specification actually, the implementation we discussed was a bit more "simple", but I personally do prefer the way you mention above.

I will take it up with the team and keep this post open for the discussion!

[swantzter]

Hi, I disagree with going down this path.
I think it's good the library is able to parse any of those four formats, but I don't think it should be able to output format's that aren't "spec-compliant"¹.

In the vein of "the only thing better than perfect is spec-compliant" I see a risk where this causes more harm than good by "encouraging" these invalid formats, which in turn just fractures the "ecosystem" even more than the mess we already have.

That said, if you have to go with one, I'd prefer the enum approach - at least there'd be some limit to the chaos

Footnotes

1. see Lag 1991:481 § 18, 4 st., and Prop. 1997/98:9, section 10 where it states the only valid short format is YYMMDD[+-]NNNC, and the long format is 12-chars long (YYYYMMDDNNNC) ↩

[PumpedSardines]

@swantzter maybe it's not wise to support extending the formatter and creating custom formats, but i'm not sure i agree with following Swedish law is the right call for what a personnummer can look like. The other two formats I mentioned are wildly used, even though they're not officially recognised.

But to encourage the use of the official formats, maybe we should name the other 2 unofficial formats to something like UnofficialTwelveDigitHyphen?