Share via

Orcas October CTP available - Hello, "System.DateTimeOffset"!

  • Article

Once again, I am very excited that the new CTP is available. :) My second feature for Orcas is available to the world! The BCL team has gotten plenty of feedback (as you can see the comments from my BCL post and on this blog...) about needing an object to represent exact point in time! (We do listen!!)

Oh and for those of you who has been reading my blog regularly... this is the third most debated name on the BCL: "DateTimeOffset". I will explain why later this month in my "Desiging DateTimeOffset" posts. Again, a starter guide will be posted on the BCL blog very soon. This time, I think our new PM Justin will be doing it instead of me. I still need to write a "Advance feature for TimeZone2".

 A new date time data structure that can specify an exact point in time relative to the UTC time zone.

  • The current DateTime is insufficient at specifying an exact point in time. DateTimeOffset represents a date time with an offset. It is not meant to be a replacement for DateTime; it should be used in scenarios involving absolute points in time. DateTimeOffset includes most of the functionality of the current DateTime API and allows seamless conversion to DateTime as well.

Again, for my loyal readers here... a little sneak preview

void CreatingADateTimeOffset()

{

 

    DateTime currentDateTime = GetUserDateTime();

    TimeSpan userOffset = GetUserOffset();

    DateTimeOffset pointInTime = new DateTimeOffset(currentDateTime , userOffset);

}

Comments

  • Anonymous
    December 10, 2006
    Yeah! (I think I was one of those people who complained :-) This is great (although at least the new local/utc/undefined bits in DateTime already get us part of the way). Now, if we can just get seamless support through to the database...  

  • Anonymous
    December 15, 2006
    Kathy -- I am worried that a new type is not needed -- you merely need to fix the type (DateTime) that is there. DateTime is already documented as "Represents an instant in time"; the only problem is that it does not implement this very well because it mixes display/formatting issues in with the instant in time. Adding an offset makes this worse, it does not fix the problem. For example; 03:00+00:00 and 14:00+11:00 represent THE SAME INSTANT IN TIME, the only difference is that they are FORMATTED DIFFERENTLY. To give a similar example, 13.5% and 0.135 both represent exactly the same value, they are merely formatted differently. This formatting is only done at display time; internally a number only stores the actual value. You don't see an "IsPercent" property on Decimal do you? Similarly, I suggest that the existing DateTime needs to do this correctly, so that, for example, comparisons work ('03:10+00:00' > '14:00+11:00' should be true, as should '03:00+00:00' == '14:00+11:00') -- currently these do not, i.e.  DateTime local = DateTime.Now;  DateTime utc = DateTime.UtcNow;  Console.WriteLine( local < utc ); Ouputs False, even though clearly utc is after local. To fix this you need to remove the Kind (with 3 offset options) from handling of DateTime, not add more offset options. It would probably be easiest to then always store the underlying UTC ticks "instant in time"; similar to how a Decimal stores the underlying correct value. Timezone, or offset, should then only ever be relevant when you want to format or display the value. I suppose for ease of use you could store a 'default' way of displaying the output as a shortcut. i.e. Most users may want to be able to have DateTime.Now.ToString() output the local time, but this should be achieved by formatting at the time out output, not by storing different underlying "instant in time" values.

  • Anonymous
    June 14, 2007
    One thing we haven&#39;t publicized much on this blog yet is a new date time structure we&#39;ve added

  • Anonymous
    August 14, 2007
    Regarding database support for DateTimeOffset, the time has arrived.  Check out the July CTP for SQL Server 2008 at http://msdn.com/sql.

  • Anonymous
    April 03, 2008
    One thing we haven't publicized much on this blog yet is a new date time structure we've added in .NET

  • Anonymous
    December 07, 2008
    The article 'A TimeZone Aware DateTime Implementation' by steinard is now available at: http://www.codeproject.com/KB/cross-platform/TimeZoneAwareDateTime.aspx An implementation that wraps DateTime to allow for keeping track of TimeZone state.