On 8 March 2012 15:56, Jonathan M Davis <jmdavisp...@gmx.com> wrote: > On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote: >> On 07/03/2012 08:10, Jacob Carlborg wrote: >> <snip> >> >> > Yeah, Clock.now() would be good and Data.today() as well. >> >> My utility library has, for consistency, DateValue.now, TimeValue.now and >> DateTime.now. > > I specically avoided giving a way to get the time with any type other than > SysTime (and TickDuration for using a monotonic clock), because I believe that > it leads to incorrect behavior. Any time that you're dealing with the system > clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are > for when you need the date and/or time but don't care about what absolute time > it's associated with in the real world. Treating DateTime as corresponding to > a specific point in time is just going to cause problems, because it has no > time zone. It could correspond to over 24 different times. By restricting > getting the time to SysTime, it encourages the writing of correct code. > > - Jonathan M Davis
It tends to be better to go for proper timezoned code from the outset, a workmate just had to add timezone support to the entire app recently, took him about 2 weeks. -- James Miller