Wednesday, February 25, 2004 - Posts
A new MSDN article gives eight best practices on using DateTime:
- When coding, store the time-zone information associated with a DateTime type in an adjunct variable.
- When testing, check to see that stored values represent the point-in-time value you intend in the time zone you intend.
- When coding, be careful if you need to perform DateTime calculations (add/subtract) on values representing time zones that practice daylight savings time. Unexpected calculation errors can result. Instead, convert the local time value to universal time, perform the calculation, and convert back to achieve maximum accuracy.
- When testing, calculate the value you expect to see in the XML string that is serialized using a machine local time view of the point in time being tested. If the XML in the serialization stream differs, log a bug!
- When writing code to serialize classes that have DateTime member variables, the values must represent local time. If they do not contain local time, adjust them prior to any serialization step, including passing or returning types that contain DateTime values in Web services.
- When coding, make DateTime member variables private and provide two properties for manipulating your DateTime members in either local or universal time. Bias the storage in the private member as UCT time by controlling the logic in your getters and setters. Add the XML serialization attributes to the local time property declaration to make sure that the local time value is what is serialized (see example).
- When testing, if your programs accept user input specifying date and time values, be sure to test for data loss on "spring-ahead", "fall-back" 23- and 25-hour days. Also make sure to test for dates gathered on a machine in one time zone and stored on a machine in another time zone.
- When you are coding and desire to store current time represented as universal time, avoid calling DateTime.Now() followed by a conversion to universal time. Instead, call the DateTime.UtcNow function directly.
Caveat: If you are going to serialize a class that contains a DateTime value, be sure that the value being serialized does not represent Universal time. XML serialization will not support UCT serialization until the Whidbey release of Visual Studio.
Mark Nottingham, of BEA Systems and one of the authors of PASwA, explains XOP and MTOM. Mark maintains the Atom Specification. Looks like Don Box will finally climb on board.
Where to find MTOM.
Omri Gazitt, Microsoft program manager for web services, is hinting that WSE 2.0 is nearing completion. Looks like his team is gunning for a hair color change.
I hadn't gotten any replies to my post concerning Microsoft's support of XOP (MTOM) for Web Services. I found my answer:
MTOM has shown up on MSDN. Note that DIME, SwA, and PASwA are marked as superseded.
The question, of course, is whether it will be supported by Indigo or will we have to wait? When will Axis have support?
|
From Miguel de Icaza's, blog:
Mainsoft's J2EE product (Permalink)
A fascinating product from Mainsoft has been released: Visual MainWin for J2EE.
This product lets you run your ASP.NET applications written in C# or VB.NET inside a J2EE application server and integrates beautifully with Visual Studio.NET. All .NET applications can also use EJBs and reference Java classes, you can see a live Flash demo of it.
Mainsoft has been using Mono's class libraries to deliver the functionality and they are regular contributors to the code base. We wish them much luck with their new product.
.NET keeps encroaching on Java! ASP.NET on one side and even DB2 CLR on the other! You can join the party any time, Oracle.
|
Microsoft released a
guide to prepare developers for Windows XP SP2. Unfortunately there was no mention of an upgrade to the
Microsoft BITS Api so that ISV's could leverage that technology for their own applications. I'm still hoping there is one. Maybe
Duncan Mackenzie can fill us in?