Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Thursday, March 08, 2012 16:18:39 James Miller wrote:
> On 8 March 2012 15:56, Jonathan M Davis <jmdavisProg at 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.

Definitely. The whole reason that I wrote std.datetime and that SysTime works 
the way that it does is because I've had to deal with enough time-related bugs 
at work that I was sick of it, and I wanted to make sure that D had a solution 
that did it right. And by maintaining its time in UTC internally and just 
adjusting the time to a particular time zone when required for output (e.g. 
getting the year of the SysTime or converting it to a string), a whole host of 
conversion errors are avoided (DST is _the_ largest mistake with regards to 
time in the history of computing IMHO).

Unfortunately, errors are still possible (e.g. sometimes you have to create a 
SysTime from a DateTime, and that can't be done without risking DST-related 
errors), but I believe that SysTime manages to reduce them about as much as is 
possible. So, in general, if you use SysTime, time should just be handled 
correctly without you having to worry about all of the details - like the time 
zone. But it also gives you the power to do more if you _do_ care about the 
details (e.g. selecting a specific time zone).

- Jonathan M Davis