Reputation: 2169
I have a Rest ws in c#. With this ws, I can put a date time with millisecond. This is an example of my request:
{ "sensorId": 656,
"value": "128",
"timestamp": "2016-06-01 11:20:50.125",
"values":
[{"value":"2064","timestamp":"2016-06-09 13:23:50.100"}]
}
As you can see there are two date with millisecond. The first date, finish with .125 millisecond.
In my code I use this code to deserialize the field Date.
public class SensorDateTimeConverter : DateTimeConverterBase//IsoDateTimeConverter
{
private const string Format = "yyyy-MM-dd HH:mm:ss.fff";
public override void WriteJson(JsonWriter writer,
object value,
JsonSerializer serializer)
{
writer.WriteValue(((DateTime)value).ToString(Format));
writer.Flush();
}
public override object ReadJson(JsonReader reader,
Type objectType,
object existingValue,
JsonSerializer serializer)
{
if (reader.Value == null)
{
return null;
}
var s = reader.Value.ToString();
DateTime result;
if (DateTime.TryParseExact(s,
Format,
CultureInfo.InvariantCulture,
DateTimeStyles.None,
out result))
{
return result;
}
return DateTime.Now;
}
}
If I try to inspect on the method ReadJson the data are correctly parse and the millisecond is "125".
If I try to save this value of my database I see the same date but with .127 millisecond.
Why?
Upvotes: 2
Views: 751
Reputation: 137188
If I try to save this value of my database I see the same date but with .127 millisecond.
Assuming that you're saving to an SQL database as a datetime
this is the limit of the precision you can get:
datetime values are rounded to increments of .000, .003, or .007 seconds, as shown in the following table.
If you want more precision then you should use different column types:
Use the time, date, datetime2 and datetimeoffset data types for new work. These types align with the SQL Standard. They are more portable. time, datetime2 and datetimeoffset provide more seconds precision. datetimeoffset provides time zone support for globally deployed applications.
(From the same page with added emphasis).
The datetime2
page has more information on this structure and its limitations.
Upvotes: 2
Reputation: 171236
If I try to inspect on the method ReadJson the data are correctly parse and the millisecond is "125".
This tells you that the problem is not with JSON conversion. All the code posted is therefore unrelated to the problem. You already succeeded in bisecting where the problem is but you investigated the wrong partition.
SQL Server's datetime
datatype has limited precision. Use datetime2
.
Upvotes: 3