1

My application is standalone windows application. Database is SQL Server 2008 onward. The application will be deployed on systems around the globe. User should view the date/time values in their own culture.

There are some Date, Time and DateTime columns in database. Should I store them:

  • based on SQL Server Date/Time?
  • based on Windows Date/Time?
  • based on Windows Date/Time converted to UTC?

I think I do not need to look into this globalization part at all as the application is standalone and databases are never going to be shared. Data will stay at same machine only, it will not be moved to central location. So, second option is best suited I guess.

I read this question and its answer. DateTimeOffset looks odd; it is generally used for row versioning. I am not sure if it is needed here. That answer is not even accepted; not sure if it really helped OP.

Amit Joshi
  • 121
  • 7

1 Answers1

1

With stand-alone systems which will never be merged using the local system clock's time has appeal. There is no need for conversion going into nor coming from the database. What you see is what you get. No matter how you access the DB, whether application, reports or ad hoc query the results need no post-processing.

However .. some places observer daylight saving. This means that once (?) a year there will be an hour-long gap in the data. And once (?) a year there will be an hour-long time reversal where, say, sorting on identity column and sorting on a datetime column will produce different ordering.

Now, we don't know your application. We don't know how important any of this could be, or what other work-arounds you might think up, or whether a crazy hour here or there is a problem or not, or any of the other factors that might come into play. But if it is then UTC or time offset is the way to go.

Michael Green
  • 25,255
  • 13
  • 54
  • 100