Feature proposal: remove implicit construction of DateTimeOffset from DateTime

[slavanap]

Specifically these 2 lines of code
https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/shared/System/DateTimeOffset.cs#L825-L826

public static implicit operator DateTimeOffset(DateTime dateTime) =>
            new DateTimeOffset(dateTime);

Misleading usecase is that TimeZoneInfo.ConvertTime has 2 overloads for DateTime and DateTimeOffset. When result of the first one is assigned to DateTimeOffset typed variable, DateTimeOffset record with local time zone offset is created. This is unclear for common code reader there's something unintended behaviour may take a place ((hey, I've supplied date, time and timezone to this function, and expect it to return date&time object for this timezone)), because types of either DateTime or DateTimeOffset that comes to ConvertTime argument may be masked by complex computational expression.

---

If the person wants to shoot their leg, let them do it, but explicitly.

[slavanap]

Here's very basic example of the case described

using System;
using System.Linq;
					
public class Program
{
    public static readonly DateTime Epoch =
        new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
    
    public static readonly TimeZoneInfo EST =
        TimeZoneInfo.GetSystemTimeZones()
            .Where(x => x.Id == "Eastern Standard Time")
            .SingleOrDefault()
        ?? TimeZoneInfo.FindSystemTimeZoneById("America/New_York"); 


    public static DateTimeOffset UnixEpochToDateTimeOffsetInEST(long msVal)
    {
        return TimeZoneInfo.ConvertTime(Epoch.AddSeconds(msVal), EST);
    }

    public static void Main()
    {
        var now = DateTimeOffset.Now;
        Console.WriteLine("Local time = {0}", now);
        Console.WriteLine("UTC time = {0}\n", now.UtcDateTime);


        var epochNow = Convert.ToInt64((now.UtcDateTime - Epoch).TotalSeconds);
        Console.WriteLine("EST time = {0}", UnixEpochToDateTimeOffsetInEST(epochNow));

        // here you get correct time in EST, but local offset.
    }
}

[slavanap]

I think, marking this implicit operator as obsolote may show a lot of bugs around it.

[davidfowl]

Roslyn Analyzer?

[Joe4evr]

Or how about Better Obsoletion?

[bartonjs]

This seems better as an analyzer. The breaking change would be very disruptive, and it should be relatively rare that something accepts both DateTime and DateTimeOffset via overloads.

I'd even limit the analyzer to identifying the confusing cases, where a DateTime is provided to a method that takes a DateTimeOffset in an overload and the output of that method is a DateTime that is implicitly converted.

Or maybe it's specifically a problem with TimeZoneInfo.ConvertTime(DateTime, TZI)

[slavanap]

it should be relatively rare that something accepts both DateTime and DateTimeOffset via overloads.

A DateTimeOffset typed variable can be constructed from either DateTime or DateTimeOffset.

This case is pretty often and dangerous when one works with DateTimeOffset typed variables and time conversions.

Please let me know if the basic example of the issue above that I've listed is not clear.

[slavanap]

Don't get me wrong, I'm not for removing the constructor, I'm for removing the implicit construction. The one who wants to construct DateTimeOffset from DateTime will still be able to do it, but such obsoletion will force them to list this conversion explicitly, e.g. new DateTimeOffset(DateTime.Now)