Is an adapter the right pattern für external SOAP clients?

My software is a Java EE application which talks to another service via SOAP. I want to create a layer that is better testable and use an ideal solution for that. I am not sure which pattern is the right one for this issue.

I have an internal data class which is called InputData. It uses locically correct data types. The SOAP interface on the other hand needs most of the data in strings, like dates in "dd.MM.yyyy", boolean as "0" and "1" and some other weird rules. I cannot change that.

So I need a layer between that. First I thought the best way was to use pure functions because they are easier to test without any side effects. My idea was to create a class with static methods of which one is public. I should return a ValueObject which holds all the data in the correct format.

I had trouble finding a name, so I started with "Adapter". But having something like this:

public class SoapDataAdapter {
    public static SoapData getSoapData(InputData input) {
        SoapData data = new SoapData();

        data.setDate = getDate(input.getDate());
        data.isCustomer = isCustomer(input.isCustomer());
        // and many more

        return data;
    }

    private static String getDate(LocalDate date) {
        return DateHelper.toSoapDate(date);
    }

    private static String isCustomer(boolean isCustomer) {
        return isCustomer ? "0" : "1";
    }
}

But this is not an Adapter according to the known patterns. But it is not a Factory -- if I go with the definition of the Gang of Four -- either.

Then I was not sure how to call it or if a "real" Adapter would be a better option. So I tried this:

public class SoapDataAdapter {
    private InputData input;

    public SoapData getSoapData(InputData input) {
        this.input = input;
    }

    public String getDate() {
        return DateHelper.toSoapDate(input.getDate());
    }

    public String isCustomer() {
        return input.isCustomer ? "0" : "1";
    }
}

The GoF design patterns gather around OOP which is probably not always the best solution. Having just those pure functions makes a lot of sense to me instead of having the overhead of creating an instance and holding the state. Also, my goal is to make it easier to understand and much easier to test.

1. What do you think is the best solution for the problem? The first, the second or even another solution? (Adapter seems to be the pattern that fits for exactly that problem, if I understood it correctly.)
2. What would you call the first one? Is Factory here acceptable?