One of the things I think we should do it support first class TimeSpan literals. I think since it could get confusing using nanoseconds everywhere, that the math will leave lots of rooms for bugs to creep in. My thinking is that a TimeSpan literal is just an integer or real with a special prefix:
Potentially do microsecond or day, but that seems uncommon.
andySun 11 Dec 2005
And what, you'll handle conversions and stuff for me?
brianSun 11 Dec 2005
There isn't a conversion - it is just a literal.
So "1min" will turn into "new TimeSpan(60_000_000_000)"
As you can see when working with nanoseconds, the literals are quite handy.
andySun 11 Dec 2005
Oh, so you are treating TimeSpan like String then. I like that - but my only concern is it common enough to warrant special attention to? I would say dates are more common than TimeSpans?
brianSun 11 Dec 2005
Dates are more commonly used, but not hardly ever declared as literal. For example when was the last time in code that you wanted to say 7-Jun-05T13:21? On the rare occassion you can just use the Time factory method that accepts ISO time.
I think TimeSpan isn't as common as Str, Int, Bool obviously. But is commonly used, and the main reason I want to give it a literal representation is that we are using nanoseconds as our standard time granularity which will require lots and lots of zeros in normal code.
brianMon 12 Dec 2005
These are implemented as described to create a TimeSpan instance. I used ns, ms, sec, and min, and hr as allowable suffixes (must be lower case).
brianMon 26 Dec 2005
I added days too, which from there can easily be used to do things like 30days or 365days (although really methods on Time will provide lots of convenience stuff too).
johnThu 29 Dec 2005
Days are much more tricky because due to daylight savings time, not every day is 24 hours. Sounds ridiculous, but trust me, that will become a pain in the ass. I don't think we should have a literal for days.
brianThu 29 Dec 2005
That's a boundary condition that is immaterial in 99.9% cases. If you don't provide days, then people will just do xhr*24.0 instead which hardly seems better. Plus in terms of relative time, I think just about anyone would say 1 day == 24 hours. What you are are touching on is really a Time issue, not a Timespan issue:
brian Sat 10 Dec 2005
One of the things I think we should do it support first class TimeSpan literals. I think since it could get confusing using nanoseconds everywhere, that the math will leave lots of rooms for bugs to creep in. My thinking is that a TimeSpan literal is just an integer or real with a special prefix:
ns: nanoseconds, 5ns ms: milliseconds, 100ms sec: seconds, 0.5sec min: minutes, 30min hr: hours, 6hr
Potentially do microsecond or day, but that seems uncommon.
andy Sun 11 Dec 2005
And what, you'll handle conversions and stuff for me?
brian Sun 11 Dec 2005
There isn't a conversion - it is just a literal.
So "1min" will turn into "new TimeSpan(60_000_000_000)"
As you can see when working with nanoseconds, the literals are quite handy.
andy Sun 11 Dec 2005
Oh, so you are treating TimeSpan like String then. I like that - but my only concern is it common enough to warrant special attention to? I would say dates are more common than TimeSpans?
brian Sun 11 Dec 2005
Dates are more commonly used, but not hardly ever declared as literal. For example when was the last time in code that you wanted to say
7-Jun-05T13:21? On the rare occassion you can just use the Time factory method that accepts ISO time.I think TimeSpan isn't as common as Str, Int, Bool obviously. But is commonly used, and the main reason I want to give it a literal representation is that we are using nanoseconds as our standard time granularity which will require lots and lots of zeros in normal code.
brian Mon 12 Dec 2005
These are implemented as described to create a TimeSpan instance. I used ns, ms, sec, and min, and hr as allowable suffixes (must be lower case).
brian Mon 26 Dec 2005
I added days too, which from there can easily be used to do things like 30days or 365days (although really methods on Time will provide lots of convenience stuff too).
john Thu 29 Dec 2005
Days are much more tricky because due to daylight savings time, not every day is 24 hours. Sounds ridiculous, but trust me, that will become a pain in the ass. I don't think we should have a literal for days.
brian Thu 29 Dec 2005
That's a boundary condition that is immaterial in 99.9% cases. If you don't provide days, then people will just do xhr*24.0 instead which hardly seems better. Plus in terms of relative time, I think just about anyone would say 1 day == 24 hours. What you are are touching on is really a Time issue, not a Timespan issue: