On Tue, 21 Oct 2008, jonwood wrote: > mikewhit wrote: >> >> Using UTC in the DB stops you going mad when something happens >> on the DST changeover (localtime hours vanish, or happen twice), >> or you have systems running in or across different countries. >> >> It also means you can subtract two times and always get the right answer >> for elapsed time ! >> > > Yes, as pointed out in my original post, I've heard the arguments for using > UTC time. Folks are just going to need to trust me to make the decision as > to how appropriate this approach is for my particular project. > > BTW, MS SQL Server doesn't do anything like this as far as I know. Given > some of the comments here, one might wonder how those poor MS SQL Server > folks are able to get anything working at all. ;-)
SQLServer folks use UTC datetimes, if their design requires it, by invoking the GetUTCDate() function: SQLServer: INSERT INTO foo (somedatetime) VALUES(GetUTCDate()); I suspect it is quite common, e.g., web apps built on SQLServer backends are quite likely to use UTC. At any rate, it is definitely a design decision, if one expects that local times will always work in all scenarios, but all means use local times. If design criteria change unexpectedly in the future to the point where local times become problematic, for reasons already mentioned, it will need a redesign. By using UTC from the outset, it will be robust to all possible datetime-related needs in the future. Chris _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
