Un tipo per Data solo in C #: perché non esiste un tipo di data?

Nel nostro progetto C # abbiamo la necessità di rappresentare una data senza un'ora. So dell'esistenza del DateTime, tuttavia incorpora anche un'ora del giorno. Voglio rendere esplicito che alcune variabili e argomenti del metodo sono basati sulla data . Quindi non posso usare la DateTime.Dateproprietà

Quali sono gli approcci standard a questo problema? Sicuramente non sono il primo a incontrarlo? Perché non esiste una Dateclasse in C #?

Qualcuno ha una bella implementazione usando una struttura e forse alcuni metodi di estensione su DateTime e magari implementando alcuni operatori come == e <,>?

Consentitemi di aggiungere un aggiornamento a questa domanda classica:

• La libreria Noda Time di Jon Skeet è ora abbastanza matura e ha un tipo di sola data chiamato LocalDate. (Locale in questo caso significa solo locale per qualcuno , non necessariamente locale per il computer in cui è in esecuzione il codice.)

• Un tipo di sola data chiamato Dateè un'aggiunta proposta a .NET Core, tramite il progetto corefxlab . Lo troverai nel System.Timepacchetto, insieme a un TimeOfDaytipo e diversi metodi di estensione ai tipi esistenti.

Ho studiato questo problema in modo significativo, quindi condividerò anche diversi motivi per la necessità di questi tipi:

1. Esiste una discrepanza logica tra un valore di sola data e un valore di data a mezzanotte.

   • Non tutti i giorni locali hanno una mezzanotte in ogni fuso orario. Esempio: la transizione all'ora legale primaverile del Brasile sposta l'orologio dalle 11:59:59 all'01: 00:00.

   • Una data-ora si riferisce sempre a un'ora specifica all'interno della giornata, mentre una sola data può riferirsi all'inizio della giornata, alla fine della giornata o all'intero intervallo del giorno.

2. Associare un'ora a una data può portare alla modifica della data quando il valore viene passato da un ambiente a un altro, se i fusi orari non vengono osservati con molta attenzione. Ciò si verifica comunemente in JavaScript (il cui Dateoggetto è in realtà una data + ora), ma può accadere facilmente anche in .NET o nella serializzazione quando i dati vengono passati tra JavaScript e .NET.

3. Serializzare un DateTimecon XML o JSON (e altri) includerà sempre l'ora, anche se non è importante. Questo è molto confuso, soprattutto considerando cose come date di nascita e anniversari, dove l'ora è irrilevante.

4. Architettonicamente, DateTimeè un oggetto valore DDD , ma viola il Principio Unico Responsabilmente in diversi modi:

   • È progettato come un tipo data + ora, ma spesso viene utilizzato come solo data (ignorando l'ora) o solo come ora (ignorando la data). ( TimeSpanviene spesso utilizzato anche per l'ora del giorno, ma questo è un altro argomento.)

   • Il DateTimeKindvalore annesso alla .Kindproprietà divide in tre il singolo tipo, Il Unspecifiedtipo è davvero l'intento originale della struttura, e dovrebbe essere usato in questo modo. Il Utctipo allinea il valore in modo specifico con UTC e il Localtipo allinea il valore con il fuso orario locale dell'ambiente.

     Il problema con avere un flag separato per tipo è che ogni volta che consumi un DateTime, dovresti controllare .Kindper decidere quale comportamento adottare. Tutti i metodi del framework lo fanno, ma altri spesso lo dimenticano. Questa è veramente una violazione SRP, poiché il tipo ora ha due diversi motivi per cambiare (il valore e il tipo).

   • I due di questi portano a utilizzi API che si compilano, ma sono spesso privi di senso o hanno strani casi limite causati da effetti collaterali. Tener conto di:

     // 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 !!!
     

In sintesi, mentre a DateTime può essere utilizzato solo per una data, dovrebbe farlo solo quando ogni luogo che lo utilizza è molto attento a ignorare l'ora, ed è anche molto attento a non cercare di convertire da e verso UTC o altro Fusi orari.

Sospetto che non ci sia una Datelezione pura dedicata perché hai già DateTimechi può gestirlo. Avere Dateavrebbe portato a duplicazioni e confusione.

Se si desidera l'approccio standard, esaminare la DateTime.Dateproprietà che fornisce solo la parte della data di a DateTimecon il valore dell'ora impostato su 12:00:00 mezzanotte (00:00:00).

Ho inviato un'e-mail a refsrcfeedback@microsoft.com e questa è la loro risposta

Marcos, questo non è un buon posto per fare domande come queste. Prova http://stackoverflow.com La risposta breve è che hai bisogno di un modello per rappresentare un punto nel tempo, e DateTime lo fa, è lo scenario più utile nella pratica . Il fatto che gli esseri umani usino due concetti (data e ora) per contrassegnare i punti nel tempo è arbitrario e non è utile separarli.

Separare solo dove è garantito, non fare le cose solo per il gusto di fare le cose alla cieca. Pensa in questo modo: quale problema hai risolto dividendo DateTime in Date e Time? E quali problemi avrai che non hai adesso? Suggerimento: se si esaminano gli utilizzi di DateTime nel framework .NET: http://referencesource.microsoft.com/#mscorlib/system/datetime.cs#df6b1eba7461813b#references Vedrai che la maggior parte viene restituita da un metodo. Se non avessimo un unico concetto come DateTime, dovresti usare i parametri out o Tuple per restituire una coppia di Date e Time.

HTH, Kirill Osenkov

Nella mia e-mail mi ero chiesto se fosse perché DateTime usa TimeZoneInfo per ottenere l'ora della macchina - in proprietà Now. Quindi direi che è perché "le regole del business" sono "troppo accoppiate", me lo hanno confermato.

Ho creato una semplice struttura Date per le volte in cui hai bisogno di una data semplice senza preoccuparti della porzione di tempo, dei fusi orari, di local vs. utc, ecc.

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

Se è necessario eseguire confronti di date, utilizzare

yourdatetime.Date;

Se stai visualizzando sullo schermo usa

yourdatetime.ToShortDateString();

Consentitemi di speculare: forse è perché fino a SQL Server 2008 non esisteva alcun tipo di dati Data in SQL, quindi sarebbe stato difficile memorizzarlo in SQL server ?? E dopo tutto è un prodotto Microsoft?

Chissà perché è così. Ci sono molte decisioni di progettazione sbagliate nel framework .NET. Tuttavia, penso che questo sia piuttosto secondario. Puoi sempre ignorare la parte del tempo, quindi anche se un codice decide di fare riferimento a un DateTime non solo alla data, il codice a cui importa dovrebbe guardare solo la parte della data. In alternativa, è possibile creare un nuovo tipo che rappresenta solo una data e utilizzare le funzioni in DateTime per eseguire il lavoro pesante (calcoli).

Perché? Possiamo solo speculare e non fa molto per aiutare a risolvere i problemi di ingegneria. Una buona ipotesi è che DateTimecontenga tutte le funzionalità che una struttura del genere avrebbe.

Se è davvero importante per te, avvolgi semplicemente DateTimenella tua struttura immutabile che espone solo la data (o guarda la DateTime.Dateproprietà).

Oltre alla risposta di Robert hai anche il DateTime.ToShortDateStringmetodo. Inoltre, se si desidera davvero un oggetto Date, è sempre possibile utilizzare il pattern Adapter e racchiudere l'oggetto DateTime esponendo solo ciò che si desidera (cioè mese, giorno, anno).

C'è sempre la DateTime.Dateproprietà che interrompe la parte del tempo di DateTime. Forse puoi incapsulare o avvolgere DateTime nel tuo tipo di data.

E per la domanda sul perché, beh, immagino che dovrai chiedere ad Anders Heljsberg.

Perché per conoscere la data, devi conoscere l'ora di sistema (in tick), che include l'ora, quindi perché buttare via quelle informazioni?

DateTimeha una Dateproprietà se non ti interessa affatto il tempo.

Sì, anche System.DateTime è sigillato. Ho visto alcune persone giocare con questo creando una classe personalizzata solo per ottenere il valore della stringa del tempo come menzionato nei post precedenti, cose come:

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();
        }
    }
}

Questo forse non è necessario, dal momento che potresti facilmente estrarre GetShortTimeString da un semplice vecchio tipo DateTime senza una nuova classe

Se si utilizzano le proprietà Date o Today per ottenere solo la parte della data dall'oggetto DateTime.

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

Quindi otterrai il componente data solo con il componente ora impostato a mezzanotte.