.net Sdk Pb with Date format DD/MM/YYYY when GetDocument

.NET SDK
1

Hi,

I stored a document in my Bucket (Server 5.0) that contain a Birth Date, store in the French way : dd/MM/yyyy.

In my example, the date is 20/04/1977 ( 20 April 1977).

I’m in c#, and my destination class have a DateTime property.

I’m getting the document like that :

IDocumentResult<FuturAcquereur> document = _couchbaseConnector.BucketGiver().GetDocument<FuturAcquereur>(id);

The document.content is null, I think it’ because of the date conversion. It must think it’s MM/dd/yyyy, and don’t accept a Month = 20.
I try to force the thread’s culture with :

Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR");

It didn’t work. If I change my birthdate for this exemple 01/04/1997, no problem, the Document.Content is not null anymore.

How can I tell couchbase SDK that I’m in French culture ?
How to correct this problem ?

Steeve

2

@steeve.descarpentrie

Common practice when storing date/times is to store them in culture neutral formats (i.e. yyyy-MM-dd) so that variances in things like thread culture settings don’t affect behavior. That date format is also sortable using string sorting. Also, it’s usuable in N1QL functions when writing queries.

The Couchbase .NET SDK uses Newtonsoft.Json to serialize/deserialize documents, which defaults to working in ISO8601 format for date/times. However, you can override this behavior in a couple of ways if using dd/MM/yyyy is important for your design.

  1. Inject a custom serializer in the Serializer property of ClientConfiguration. This could be Newtonsoft.Json with different settings, which you do by creating a DefaultSerializer with different settings in the constructor. Or you can implement a completely custom serializer.

  2. Use a [JsonProperty] or [JsonConverter] attribute to alter the serialization/deserialization behaviors on your class or property.

3 Likes
3

Hi,

thank you for your anwser.

Storing the date in format dd/MM/yyyy was a mistake, I was young, It was 2 weeks ago :smile:

It was a mix betwene a string and a ToShortDateString(), shame on me.
I stored it with a true DateTime, it will be better !

Steeve

3 Likes