No it isn't. The program:

---8<---
using System;
using System.ComponentModel;

class App
{
   static void Main()
   {
       TimeSpanConverter tsc = new TimeSpanConverter();
       tsc.ConvertTo(null, null, DateTime.Now, typeof(string));
   }
}
--->8---

Produces code like this for Main():

---8<---
 .method private hidebysig static void  Main() cil managed
 {
   .entrypoint
   // Code size       36 (0x24)
   .maxstack  5
   .locals init ([0] class
[System]System.ComponentModel.TimeSpanConverter tsc)
   IL_0000:  newobj     instance void
[System]System.ComponentModel.TimeSpanConverter::.ctor()
   IL_0005:  stloc.0
   IL_0006:  ldloc.0
   IL_0007:  ldnull
   IL_0008:  ldnull
   IL_0009:  call       valuetype [mscorlib]System.DateTime
[mscorlib]System.DateTime::get_Now()
   IL_000e:  box        [mscorlib]System.DateTime
   IL_0013:  ldtoken    [mscorlib]System.String
   IL_0018:  call       class [mscorlib]System.Type
[mscorlib]System.Type::GetTypeFromHandle(valuetype
[mscorlib]System.RuntimeTypeHandle)
   IL_001d:  callvirt   instance object
[System]System.ComponentModel.TypeConverter::ConvertTo(class
[System]System.ComponentModel.ITypeDescriptorContext, class
[mscorlib]System.Globalization.CultureInfo, object, class
[mscorlib]System.Type)
   IL_0022:  pop
   IL_0023:  ret
 } // end of method App::Main
--->8---

You can see there at IL_001d that TypeConverter::ConvertTo is clearly
called via callvirt.

The class could be unsealed, a virtual method overridden, and the
assembly recompiled long after your code has baked in a static call to
the wrong method.

Actually, call and callvirt have different semantics even independent of
whether or not the method in question is virtual - callvirt checks for a
null instance, even if the method is static. I've written about it on by
blog:

http://barrkel.blogspot.com/2006/05/call-vs-callvirt-for-c-non-virtual.html

The C# compiler appears to only uses 'call' for calling ancestor
methods, static methods and constructors.

-- Barry