Buffer del protocollo: Devo usare int64 o fixed64 per rappresentare un valore di DateTime .NET?

Question

Ho bisogno di serializzare un valore di DateTime .NET in un messaggio di buffer di protocollo.

Il mio piano è utilizzare DateTime.ToBinary() e quindi passare il valore restituito a 64 bit nel messaggio. Ma non sono sicuro di cosa scegliere come protocollo tipo di dati del buffer per rappresentarlo.

Immagino di essere confuso su quando devono essere utilizzati i tipi di dati fixed64 (o sfixed64).

Presumo che in questo scenario utilizzerei i tipi firmati poiché i valori restituiti da DateTime.ToBinary() possono essere negativi e positivi.

Answer 1

Bene, si desidera che sia int64 o sfixed64 per far fronte al valore firmato.

Avendo appena eseguito un test rapido, DateTime.Now.ToBinary() è codificato in 10 byte utilizzando int64 mentre sfixed64 utilizza sempre 8 byte. Fondamentalmente, la codifica a lunghezza variabile è ottima per i numeri piccoli, ma diventa più grande della codifica fissa per i grandi numeri. (È lo stesso tipo di compromesso rispetto all'uso di UTF-8 invece di UTF-16: i caratteri ASCII possono essere codificati in UTF-8 in un singolo byte, ma in seguito i punti di codice finiscono per essere codificati come 2 e quindi 3 byte, mentre UTF -16 utilizza sempre 2 byte per i caratteri del BMP.)

la mia ipotesi è che DateTime.ToBinary() valori sono probabile di essere abbastanza grande (senza conoscere i dettagli di esattamente ciò che fa), in modo sfixed64 è più appropriato.

Ha senso?

Answer 2

È necessario utilizzare un numero a 64 bit con segno, non perché DateTime può essere negativo, ma poiché il metodo ToBinary restituisce un , che è un numero a 64 bit con segno.

Answer 3

In protobuf-net, io uso un approccio scala graduata (e in effetti, gestisce tutto questo per voi, se è sufficiente utilizzare DateTime) - il Proto equivalente è qualcosa di simile:

message DateTime { 
    optional sint64 value = 1; // the offset (in units of the selected scale) 
          // from 1970/01/01 
    optional TimeSpanScale scale = 2 [default = DAYS]; // the scale of the 
                // timespan 
    enum TimeSpanScale { 
    DAYS = 0; 
    HOURS = 1; 
    MINUTES = 2; 
    SECONDS = 3; 
    MILLISECONDS = 4; 

    MINMAX = 15; // dubious 
    } 
} 

cioè se il DateTime può essere espresso in giorni interi, inviamo solo il numero di giorni dal 1970, ecc. più un piccolo segno alla scala. Ciò significa che le date possono essere inviate un po 'più efficientemente, ma in realtà non costa molto di più per altre scale.

Personalmente, non vorrei usare ToBinary() - Vorrei usare esplicitamente un offset di una scala nota da un'epoca conosciuta (come l'epoca unix). Questo lo rende più portabile tra le piattaforme. Ma se si sta inviando (per esempio) solo l'offset millisecondo, allora una scala fissa di solito sarebbe più efficiente di una scala di lunghezza variante. Se hai bisogno di una firma o di una firma dipende dal fatto che tu abbia bisogno di date prima della tua epoca ;-p