DateTime FAQ Entries

re: More on DateTime and TimeZones

Brad Abrams — Fri, 21 May 2004 21:35:00 GMT

re: DateTime FAQ Entries

Anthony Moore — Fri, 21 May 2004 21:58:00 GMT

[Anthony Moore]

I forgot to put my name in the blog. I would be interested in any feedback on this content.

re: DateTime FAQ Entries

Luc Cluitmans — Fri, 21 May 2004 23:16:00 GMT

Quote: "All this being said, it may be possible to create an entirely new class that does represent an absolute point in time and does have time zone context. This may be considered for a post-Whidbey release."

Given the seriousness of the problems surrounding this whole issue, wouldn't it be better to add such a second DateTime-like struct already in Whidbey? Post-whidbey is VERY far away... What are the arguments to postpone it?

Even more on DateTime...

Brad Abrams — Sun, 23 May 2004 18:23:00 GMT

re: DateTime FAQ Entries

Thomas Tomiczek — Sun, 23 May 2004 19:26:00 GMT

::If we could have seen the full implications
::of the earliest design decisions, we may
::well have begun with a UTC based DateTime
::instead.

Interesting. Someone was sleeping here.

You COULD have seen and SHOULD have seen this. This is a TYPICAL problem that ihas been plaguing the programmer community for a long time - and too vendors have been tremendously ignorant to this.

Example?

SQL - DateTime and timezone information. Added to the standard years ago, soon YUKON will be probably the first (!) database to support them.

I myself got stuck with this about 10 years ago, and have been using things UTC ever since then.

I can only support Luc here - put the additional classes into Whidbey. You have the time. Post-Whidbey is YEARS away.

re: DateTime FAQ Entries

Lee — Mon, 24 May 2004 10:45:00 GMT

I agree, we should have a new DateTime struct that uses UTC sooner rather than later.

re: DateTime FAQ Entries

Peter Ibbotson — Mon, 24 May 2004 12:07:00 GMT

We've been kicking around the same set of problems here. Most of the time it's not a big issue but having a "Date" type would be useful sometimes. Birthday is a classic example, how do you represent this in a database if the system has timezones on different days during use? You can do this by storing midnight UTC and using context to say if timezone is significant (e.g. it's not on a birthday) but it does stink slightly.

DateTime: More DateTime best practices

Ken Brubaker — Mon, 24 May 2004 18:17:00 GMT

Brad Abrams leads us to a new BCL Blog posting on DateTime by Anthony Moore.

re: DateTime FAQ Entries

Keith Hill — Wed, 26 May 2004 18:50:00 GMT

Considering the complexity of getting the correct behavior from DateTime (yikes), it does seem like you should seriously consider adding a DateTime2 (or DateUniversalTime or UniversalDateTime or DateTimeUtc) to the Whidbey release.

re: DateTime FAQ Entries

Kit George {MSFT] — Fri, 28 May 2004 21:57:00 GMT

Yup, it is something we will have to think through carefully, but we are interested in ensuring that all of the applicable scenarios for DateTimes are supported Keith: We'll keep you all posted when we have more details on where we plan to head.

Why Not Add a New DateTime Date Type in Whidbey?

BCLTeam's WebLog — Tue, 01 Jun 2004 18:45:00 GMT

re: DateTime FAQ Entries

Anthony Moore — Tue, 01 Jun 2004 18:46:00 GMT

I added a new post as a reply to this feedback:
http://weblogs.asp.net/bclteam/archive/2004/06/01/145487.aspx

re: DateTime FAQ Entries

Pawel Achtel — Fri, 04 Jun 2004 03:14:00 GMT

Microsoft has got the problem wrong for some 20 years and now they try to give recommendations...some of which are wrong again! What can I say?

We have tried (with no success) to pitch a solution to Microsoft, which is part of our very generic library based on tensor theory. The library is aimed for graphics applications, but time can be also represented as field (like gravity, or any other vector) and can undergo tensor transformations (at quite high abstraction level). By doing so, you do not care how you represent the time, or even that it is time that you are dealing with - it may be just a coordinate on a screen or a gravity. All the algorithms are generic (and lighting fast).

The result - yes, we can handle time and conversions to local including daylight saving adjustment any way you want. This is not only with much higher precision than the proposed methods, but correctly and consistently. To demonstrate this, please have a close look at two sample time scales of the graphs illustrated here: www.24x7.com.au/2d.htm
You will see that the local time is not linear; it is not even continuous. Because it is not continuous, it does not have inverse function (no conversion from Local time to UTC) - it is simply not possible and that's basic maths (non-continuous function does not have an inverse).

Dear Microsoft, if you have no idea about the problem, please consult someone who knows something about it. I would be happy to help, but please, do not make recommendations if you got it wrong every time for the last two decades, okay?

Kind Regards,

Pawel Achtel
3D Software Development
www.24x7.com.au

re: Why Not Add a New DateTime Date Type in Whidbey?

BCLTeam's WebLog — Fri, 04 Jun 2004 08:09:00 GMT

re: DateTime FAQ Entries

JD — Fri, 04 Jun 2004 17:36:00 GMT

I've got to agree that the DateTime as-is simply leads to a Pit of Failure, not of Success, and for that reason is a bad API. It's just too easy to get wrong.

I have no idea about this academic 'tensor' thing above. Regardless, UniversalDateTime makes more sense. Having one type with so many interpretations sucks, the UTC-ness is part of the type IMHO.

Your new ToBinary is just as breaking if someone tries to use it as the Ticks (which most people seeing an Int64 time field would do). Just fix it by migration, leave the old class there for those dealing with local time only or backwards compat. Let the world move forward.

re: DateTime FAQ Entries

Anthony Moore — Wed, 09 Jun 2004 05:45:00 GMT

I have some questions about the comments here. Pawel, you say that we have guidelines that are incorrect. Please indicate which ones are incorrect. We recommend converting to UTC before doing any arithmetic. Is that something you would consider incorrect? If you mean that it does not take relativety into account or that standard clocks occaisionally get tweaked by a few seconds, I would contend that this is beyond the scope of a DateTime representation for normal business use.

We are aware that ToBinary is not currently suitable for persistence accross time zones. This is something that should be addressed before we ship. If people confuse this with the Ticks, they should promptly get an argument exception.

re: DateTime FAQ Entries

Pawel Achtel — Thu, 10 Jun 2004 03:30:00 GMT

There are number of problems in your approach, and no, my concept applies to business applications as well as other common problems associated with time. Coincidentally it also allows you to correctly deal with time relativity (curved time field), but this is not the argument I make. Although, I can see nothing wrong if NASA could use DateTime and be rest assured to land on Mars and not Neptune ;-) However, the applications I had in mind are more down to earth.
I explained that your recommendation is not deterministic, therefore not possible (without at least an occasional error).
One has to understand what time is in order to come up with a right model. For example, using ticks for that purpose is like counting wrinkles on your bum to tell the age - easy but not very reliable (I have many wrinkles on my bum and I still feel young). The best way (that I found) is to model the time as a tensor object - just like gravity, stress, displacement, coordinate or even the amount of money Microsoft has in it's account (I told ya it’s generic). Having tensor object representation, it allows for certain operations, some of which may be linear, some may be continuous, and some may be reversible. Such ability allows consistent, correct and well-defined operations (such as conversion to Sydney daylight saving adjusted time, or a number of seconds since Bush became the president). Using your approach the number of seconds that Bush was the president measured in Sydney and in New York would be different! This is a fault (one of many) in your approach and you do not need to land on Neptune instead of on Mars to find it out.

I would be happy to get involved in providing a better solution for Microsoft. You can contact me directly off-line.

Kind Regards,

Pawel Achtel
3D Software Development
www.24x7.com.au

re: DateTime FAQ Entries

James Smith — Tue, 13 Jul 2004 18:01:00 GMT

Hi,

Could anyone tell me how to get a month in english format out of a Date Time object i.e. "January"?

I expect it's DateTime.ToString("something");

can anybody help?

James
EntrappaSolutions.com

re: DateTime FAQ Entries

Kit George [MSFT] — Tue, 13 Jul 2004 21:52:00 GMT

This code should do you the trick James:

using System;
using System.Threading;
using System.Globalization;

public class Temp {
public static void Main() {
DateTime dt = DateTime.Now;
Console.WriteLine(Thread.CurrentThread.CurrentCulture.

DateTimeFormat.MonthNames[dt.Month - 1]);

}
}

re: DateTime FAQ Entries

dianying xia zai — Mon, 26 Jul 2004 10:12:00 GMT

dianying xia zai:http://www.kamun.com/
movie down:http://movie.kamun.com/
mp3 xia zai:http://music.kamun.com/
engage:http://club.kamun.com/

re: DateTime FAQ Entries

Shital Shah — Wed, 28 Jul 2004 19:46:00 GMT

There is one serious problem in your recommandation to store date time format as "yyyy-MM-ddTHH:mm:ss.fffffff". This format is not acceptable by lots of COM code written in VB6, VBScript and VBA function (you always find these things in enterprise environment in obscure places like VBA functions in Access queries). The reason these functions fails is because,

1. They don't like fractional seconds part.
2. The "T" as seperator between date and time is not acceptable in some non-English local like Dutch. For example DateValue() call in VBA/VB6/VBScript getting executed in Netherlands will fail if you feed data generated by .Net program in above format.

The format that you should use if you want your data to be readable in all worlds is this:

"yyyy-MM-dd HH:mm:ss"

Yes, you loose fractions of seconds but in a realistic world, this is the only format I've found that works in all different locals with .Net and with VB6 COM and VBScript and VBA.

It would be really good to add a shortcut for this format in Whidbey because most people aren't aware of this. Its too late when you get a call from Japan that your new data generated from glorious .Net app doesn't go hand in hand with their queries fired on linked tables in Access :).

Regards,
Shital.
http://www.ShitalShah.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whenever people say "we mustn't be sentimental", you can take it they are about to do something cruel. And if they add, "we must be realistic", they mean they are going to make money out of it.

-Brigid Brophy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date

Hackward and Foreword — Sun, 31 Oct 2004 22:28:00 GMT

More DateTime related discussions during pre-Whidbey release

Kathy Kam — Fri, 28 Jul 2006 00:24:42 GMT

While doing my System.DateTime and System.TimeZone investigation, I come across some old discussions...

Ciaran’s Random Writings » Blog Archive » The Rise and Fall of Microsoft Development Tools, Part 1

Fri, 24 Aug 2007 18:38:55 GMT

PingBack from http://blog.ciarang.com/index.php/archives/19

BCL Team Blog DateTime FAQ Entries | Paid Surveys

BCL Team Blog DateTime FAQ Entries | Paid Surveys — Fri, 29 May 2009 20:18:02 GMT

PingBack from http://paidsurveyshub.info/story.php?title=bcl-team-blog-datetime-faq-entries

BCL Team Blog DateTime FAQ Entries | Best Eye Cream

BCL Team Blog DateTime FAQ Entries | Best Eye Cream — Mon, 08 Jun 2009 05:43:59 GMT

PingBack from http://besteyecreamsite.info/story.php?id=2872

BCL Team Blog DateTime FAQ Entries | Cellulite Creams

BCL Team Blog DateTime FAQ Entries | Cellulite Creams — Tue, 09 Jun 2009 05:47:34 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=11613

BCL Team Blog DateTime FAQ Entries | home lighting

BCL Team Blog DateTime FAQ Entries | home lighting — Sun, 14 Jun 2009 04:54:18 GMT

PingBack from http://homelightingconcept.info/story.php?id=154