Un tipo para fecha solo en C #: ¿por qué no hay un tipo de fecha?

En nuestro proyecto C # tenemos la necesidad de representar una fecha sin hora. Sé de la existencia de DateTime, sin embargo, también incorpora una hora del día. Quiero hacer explícito que ciertas variables y argumentos de método se basan en fechas . Por lo tanto, no puedo usar la DateTime.Datepropiedad.

¿Cuáles son los enfoques estándar para este problema? ¿Seguro que no soy el primero en encontrarme con esto? ¿Por qué no hay ninguna Dateclase en C #?

¿Alguien tiene una buena implementación usando una estructura y tal vez algunos métodos de extensión en DateTime y tal vez implementando algunos operadores como == y <,>?

Permítame agregar una actualización a esta pregunta clásica:

• La biblioteca Noda Time de Jon Skeet ahora está bastante madura y tiene un tipo de solo fecha llamado LocalDate. (Local en este caso solo significa local para alguien , no necesariamente local para la computadora donde se ejecuta el código).

• Un tipo de solo fecha llamado Datees una adición propuesta a .NET Core, a través del proyecto corefxlab . Lo encontrará en el System.Timepaquete, junto con un TimeOfDaytipo y varios métodos de extensión para los tipos existentes.

He estudiado este problema de manera significativa, por lo que también compartiré varias razones de la necesidad de estos tipos:

1. Existe una discrepancia lógica entre un valor de solo fecha y un valor de fecha a la medianoche.

   • No todos los días locales tienen una medianoche en todas las zonas horarias. Ejemplo: la transición del horario de verano de primavera hacia adelante de Brasil mueve el reloj de 11:59:59 a 01:00:00.

   • Una fecha y hora siempre se refiere a una hora específica dentro del día, mientras que una fecha solo puede referirse al comienzo del día, al final del día o al rango completo del día.

2. Adjuntar una hora a una fecha puede hacer que la fecha cambie a medida que el valor se pasa de un entorno a otro, si las zonas horarias no se observan con mucha atención. Esto ocurre comúnmente en JavaScript (cuyo Dateobjeto es realmente una fecha + hora), pero también puede suceder fácilmente en .NET, o en la serialización cuando los datos se pasan entre JavaScript y .NET.

3. Serializar un DateTimecon XML o JSON (y otros) siempre incluirá la hora, incluso si no es importante. Esto es muy confuso, especialmente considerando cosas como fechas de nacimiento y aniversarios, donde la hora es irrelevante.

4. Arquitectónicamente, DateTimees un objeto de valor DDD , pero viola el Principio Único Responsable de varias maneras:

   • Está diseñado como un tipo de fecha + hora, pero a menudo se usa solo como fecha (ignorando la hora) o solo como hora del día (ignorando la fecha). ( TimeSpantambién se usa a menudo para la hora del día, pero ese es otro tema).

   • El DateTimeKindvalor adjunto a la .Kindpropiedad divide el tipo único en tres. El Unspecifiedtipo es realmente la intención original de la estructura y debe usarse de esa manera. El Utctipo alinea el valor específicamente con UTC y el Localtipo alinea el valor con la zona horaria local del entorno.

     El problema de tener una bandera separada para el tipo es que cada vez que consume un DateTime, se supone que debe verificar .Kindpara decidir qué comportamiento tomar. Todos los métodos marco hacen esto, pero otros a menudo lo olvidan. Esta es realmente una violación de SRP, ya que el tipo ahora tiene dos razones diferentes para cambiar (el valor y el tipo).

   • Los dos conducen a usos de API que se compilan, pero a menudo no tienen sentido o tienen casos extremos extraños causados ​​por efectos secundarios. Considerar:

     // nonsensical, caused by mixing types
     DateTime dt = DateTime.Today - TimeSpan.FromHours(3);  // when on today??
     
     // strange edge cases, caused by impact of Kind
     var london = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
     var paris = TimeZoneInfo.FindSystemTimeZoneById("Romance Standard Time");
     var dt = new DateTime(2016, 3, 27, 2, 0, 0);  // unspecified kind
     var delta = paris.GetUtcOffset(dt) - london.GetUtcOffset(dt);  // side effect!
     Console.WriteLine(delta.TotalHours); // 0, when should be 1 !!!

En resumen, si bien a DateTime se puede usar solo para una fecha, solo debe hacerlo cuando cada lugar que lo usa tenga mucho cuidado de ignorar la hora, y también tenga mucho cuidado de no intentar convertir hacia y desde UTC u otro zonas horarias.

Sospecho que no hay una Dateclase dedicada pura porque ya tienes la DateTimeque puede manejarla. El tener Dateconduciría a la duplicación y confusión.

Si desea el enfoque estándar, mire la DateTime.Datepropiedad que proporciona solo la parte de la fecha de a DateTimecon el valor de hora establecido en 12:00:00 medianoche (00:00:00).

Envié un correo electrónico a refsrcfeedback@microsoft.com y esa es su respuesta

Marcos, este no es un buen lugar para hacer preguntas como estas. Tratar http://stackoverflow.com. La respuesta corta es que necesita un modelo para representar un punto en el tiempo, y DateTime lo hace, es el escenario más útil en la práctica . El hecho de que los humanos usen dos conceptos (fecha y hora) para marcar puntos en el tiempo es arbitrario y no es útil separarlos.

Solo desacople donde esté justificado, no haga las cosas por el simple hecho de hacer las cosas a ciegas. Piénselo de esta manera: ¿qué problema tiene que se resuelve dividiendo DateTime en Date y Time? ¿Y qué problemas tendrás que no tienes ahora? Sugerencia: si observa los usos de DateTime en el marco .NET: http://referencesource.microsoft.com/#mscorlib/system/datetime.cs#df6b1eba7461813b#references Verá que la mayoría se devuelve desde un método. Si no tuviéramos un concepto único como DateTime, tendrías que usar parámetros o Tuples para devolver un par de Date y Time.

HTH, Kirill Osenkov

En mi correo electrónico me pregunté si era porque DateTime usa TimeZoneInfo para obtener la hora de la máquina, en propiedad Now. Entonces yo diría que es porque "las reglas comerciales" están "demasiado acopladas", me lo confirmaron.

Creé un simple estructura de fecha para los momentos en que necesita una fecha simple sin preocuparse por la porción de tiempo, las zonas horarias, local frente a utc, etc.

https://github.com/claycephus/csharp-date

Si necesita realizar comparaciones de fechas, utilice

yourdatetime.Date;

Si está mostrando en la pantalla, use

yourdatetime.ToShortDateString();

Permítanme especular: ¿Tal vez se deba a que hasta SQL Server 2008 no había un tipo de datos de fecha en SQL, por lo que sería difícil, así que almacenarlo en el servidor SQL? ¿Y es, después de todo, un producto de Microsoft?

Quién sabe por qué es así. Hay muchas malas decisiones de diseño en el marco .NET. Sin embargo, creo que esto es bastante menor. Siempre puede ignorar la parte de la hora, por lo que incluso si algún código decide que una DateTime se refiera a algo más que a la fecha, el código que le importa solo debe mirar la parte de la fecha. Alternativamente, puede crear un nuevo tipo que represente solo una fecha y usar funciones en DateTime para hacer el trabajo pesado (cálculos).

¿Por qué? Solo podemos especular y no ayuda mucho a resolver problemas de ingeniería. Una buena suposición es que DateTimecontiene toda la funcionalidad que tendría dicha estructura.

Si realmente te importa, simplemente envuelve DateTimetu propia estructura inmutable que solo expone la fecha (o mira la DateTime.Datepropiedad).

Además de la respuesta de Robert, también tienes el DateTime.ToShortDateStringmétodo. Además, si realmente desea un objeto Date, siempre puede usar el patrón Adapter y envolver el objeto DateTime exponiendo solo lo que desea (es decir, mes, día, año).

Siempre existe la DateTime.Datepropiedad que corta la parte de tiempo del DateTime. Tal vez pueda encapsular o envolver DateTime en su propio tipo de fecha.

Y para la pregunta de por qué, bueno, supongo que tendrá que preguntarle a Anders Heljsberg.

Porque para saber la fecha, debes conocer la hora del sistema (en tics), que incluye la hora, entonces, ¿por qué tirar esa información?

DateTimetiene una Datepropiedad si no le importa en absoluto el tiempo.

Sí, también System.DateTime está sellado. He visto a algunas personas jugar con esto creando una clase personalizada solo para obtener el valor de cadena del tiempo como se menciona en publicaciones anteriores, cosas como:

class CustomDate
{
    public DateTime Date { get; set; }
    public bool IsTimeOnly { get; private set; }

    public CustomDate(bool isTimeOnly)
    {
        this.IsTimeOnly = isTimeOnly;
    }

    public string GetValue()
    {
        if (IsTimeOnly)
        {
            return Date.ToShortTimeString();
        }

        else
        {
            return Date.ToString();
        }
    }
}

Esto tal vez sea innecesario, ya que podría extraer fácilmente GetShortTimeString de un tipo DateTime antiguo sin una nueva clase

Si usa las propiedades Fecha o Hoy para obtener solo la parte de la fecha del objeto DateTime.

DateTime today = DateTime.Today;
DateTime yesterday = DateTime.Now.AddDays(-1).Date;

Entonces obtendrá el componente de fecha solo con el componente de tiempo configurado en medianoche.