views:

908

answers:

3

I have high precision dates stored in an SQL server, e.g.

2009-09-15 19:43:43.910

However when I convert that value into a DateTime the miliseconds value of the resulting DateTime value is 0:

reader["Timestamp"] = 15/09/2009 19:43:43.000

Having these DateTime values in precision down to milliseconds is very important to me - what is the best way of doing this?

UPDATE: This is the code that performs the conversion:

DateTime myDate = (DateTime)reader[Timestamp"];

There is nothing special about the SELECT statement, in fact it is a SELECT * - no fancy casts or anything

It appears that the DateTime object returned by the SqlDataReader simply is not populated with the Millisecond value

+3  A: 

Maybe this (Difference between DateTime in c# and DateTime in SQL server) will help a little.

Lukasz Lysik
It helps a littel, but that article explains that the DateTime type has more precision that the SqlDateTime type - where is this precision being lost?
Kragen
A: 

That is because the default format string for DateTime doesn't include milliseconds.

If you use a custom format, you will see the milliseconds value.

An example:

  public class Program
  {
    private static string connString = @"Data Source=(local);Initial Catalog=DBTest;Integrated Security=SSPI;";
    public static void Main(string[] args)
    {
      using (SqlConnection conn = new SqlConnection(connString))
      {
        conn.Open();

        using (SqlCommand cmd = new SqlCommand("SELECT * FROM MilliSeconds"))
        {
          cmd.Connection = conn;

          SqlDataReader reader = cmd.ExecuteReader();
          while(reader.Read())
          {
            DateTime dt = (DateTime)reader["TimeCollected"];
            int milliSeconds = dt.Millisecond;
            Console.WriteLine(dt.ToString("yyyy-MM-dd HH:mm:ss.fff"));
          }
        }
      }

      Console.ReadLine();
    }
  }

From a database with these values:

1   2009-09-22 18:11:12.057 
2   2009-09-22 18:11:28.587 
3   2009-09-22 18:11:29.820

The resulting output from the code above is:

2009-09-22 18:11:12.057 
2009-09-22 18:11:28.587 
2009-09-22 18:11:29.820
Magnus Johansson
Sorry, its not that Timestamp.ToString("yyyy-MM-dd HH:mm:ss.fff") returns 19:43:43.000 - note that the millisecond values are all 0 when they are 910 on the database.
Kragen
Well, I disagree with you. I have added the resulting output from my example code.
Magnus Johansson
A: 

Here's how I'd try to troubleshoot this:

  1. step through in the debugger and look at the type and value of reader[Timestamp"]. If the type is not SqlDateTime, that would make me suspicious-- I'd then look at the query to figure out why that column was returning another type instead of DATETIME (or DATETIME2, etc.)

  2. if that value is SqlDateTime and it does contains milliseconds, then I'd look at the cast as the source of the problem. To validate this, I'd try (in debugger or code) SqlDataReader.GetDateTime() and SqlDataReader.GetSqlDateTime() to see if either returns the correct result. This admittedly seems really unlikely as source of the problem-- casting should work fine.

  3. if that value from #1 is SqlDateTime but contains no milliseconds, then I'd look to an upstream problem in the database-- in other words your query is returning something without milliseconds. when you execute the exact same query in Management Studio, do you see milliseconds?

My guess is this is a query-related issue. But am intrigued to find our more.

Justin Grant
The type of reader["Timestamp"] is System.DateTime - attempting to cast into a SqlDateTime fails.
Kragen
The query is a simple "SELECT * FROM ..." - the ... is in this case very complex, however I've executed the exact same query in Sql Server Management Studio and see then Milliseconds value.
Kragen
What do you get when you use reader.GetSqlDateTime() ? Also, another possibility might be (if your "..." is a join) that there are two coulmns from different tables with the same name but with different values. That's easy to test by replacing * with one coulumn name in your query.
Justin Grant
Turns out my problem was with the query after all - I had to capture a profiler trace and execute the exact query and the milliseconds value came up empty.
Kragen