REQUEST: Add type validation and exceptions when MixpanelNameAttribute is assigned to a property with an incompatible type

[DanielCaspers]

As I discovered in #16, it is possible to assign the attribute to a property which will not work for the special Mixpanel property it is supposed to be used for.

In my case, I was assigning a UtcDateTime to the Mixpanel time property, which requires as a long in the format of milliseconds since epoch. As the HTTP API doesn't warn of it being malformed, I feel it would be a helpful improvement to this library to have an exception thrown when these types are mismatched.

Thank you for all of the work you have into this library.

[eealeivan]

As I understand UtcDateTime is not a part of standard library. Can you please tell where it is coming from?

[DanielCaspers]

@eealeivan I am sorry for not catching this detail earlier. The UtcDateTime used in the project I was working on was a home grown convenience wrapper around the standard library DateTime object, as it needed Unix Time functions for other reasons prior to Microsoft including it in the .NET 4.6 release in DateTimeOffset.

However, I feel this could still be a worthy area for improvement. MixPanel will only accept a long, so having the C# attribute check that the type is valid for MixpanelProperty.Time seems like a good way to prevent future developers from making the same mistake I made. Even if I had sent a standard library DateTime, it wouldn't have been right because of the ToString() that would have implicitly happened when I mapped it.

It may also be worth a <remark> tag in the docs for MixpanelProperty.Time as sometimes devs aren't always x-referencing with the HTTP API docs.

Thanks for the quick response!

[eealeivan]

I will definitely improve the documentation.

Currently the following types are supported for time special property: DateTime, DateTimeOffset or long.

public static ValueParseResult ParseUnix(object rawDateTime)
{
    switch (rawDateTime)
    {
        case null:
            return ValueParseResult.CreateFail("Can't be null.");

        case DateTime dateTime:
            return ValueParseResult.CreateSuccess(
                ToUnixTime(dateTime.ToUniversalTime().Ticks));

        case DateTimeOffset dateTimeOffset:
            return ValueParseResult.CreateSuccess(
                ToUnixTime(dateTimeOffset.ToUniversalTime().Ticks));

        case long unixTime:
            return ValueParseResult.CreateSuccess(unixTime);
            
        default:
            return ValueParseResult.CreateFail(
                "Expected types are: DateTime, DateTimeOffset or long (unix time).");
    }

    long ToUnixTime(long ticks)
    {
        return (ticks - UnixEpoch) / TimeSpan.TicksPerSecond;
    }
}

[DanielCaspers]

I'm kinda curious which case my code would have been running into with this... I assume I would have hit the default case when it was mapped by Automapper to a string. I might have been missing those ValueParseResult objects because I wrote the analytics stack to process on a background thread. Would it still continue the request with a failed parse? What behavior happens next?

Thanks for the code example; it helps a lot!