4

I have run into what seems like an error with either PostgreSQL or the Devart database connection library. The following is a simple test app I created:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace DateTimeOffsetTest
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var context = new Context())
            {
                var e = new Ent() { CreatedOn = DateTimeOffset.Now };
                Console.WriteLine(e.CreatedOn.UtcDateTime.Ticks);
                context.Ents.Add(e);
                context.SaveChanges();
            }

            using (var context = new Context())
            {
                var ent = context.Ents.Single();

                Console.WriteLine(ent.CreatedOn.UtcDateTime.Ticks);
                Console.Read();

                context.Ents.Remove(ent);
                context.SaveChanges();
            }
        }
    }
}

I would expect that the two lines being written to the console would be the same, but the second one always has a 0 in the last digit. Example:

Test output

Is this a precision issue with the way PostgreSQL is setup and if so, can I change that somehow? This test works fine if I am using SqlServer as my database.

GBreen12
  • 1,832
  • 2
  • 20
  • 38

1 Answers1

3

If CreatedOn is a PostgreSQL timestamp the precision is 1 microsecond. 1 tick is .1 microseconds.

bubi
  • 6,414
  • 3
  • 28
  • 45
  • I see, is there any way to increase the timestamp precision? I'm assuming not – GBreen12 Jul 02 '15 at 16:04
  • You could store the ticks. 64 bits integer (bigint) is enough for your timestamps. If you don't like to use ticks in your program you could store the ticks as backing field then use a DateTime not mapped field – bubi Jul 02 '15 at 16:06
  • Good idea, I may have to do that. Thanks for the help – GBreen12 Jul 02 '15 at 16:11