Scott Hanselman's ComputerZen.com

A fellow emailed me about some trouble he was having with WSE (Web Services Enhancements) and Timestamp Expiration.  He was getting a SOAP Exception (Timestamp Fault) and figured it was because his machines were in different timezones.  This is what I told him:

This isn’t neccessarily an issue of maturity of the toolkit, it’s simply how TimeStamping (TTL) works on Web Services. Personally, I run my Web Servers on GMT/Universal Time to avoid even thinking about Timezones.  Either way, it’s really about Universal Time (UTC).  When you see a DateTime (when sniffing) in a Created or Expires you’ll notice that they append a “Z” (http://www.w3.org/TR/NOTE-datetime and http://www.learnmobile.net/MobileClient/Tutorials/cfWSE/) that indicates the DateTime is in UTC.  Note: 1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time. 1994-11-05T13:15:30Z corresponds to the same instant. (note: http://msdn.microsoft.com/webservices/building/wse/default.aspx?pull=/library/en-us/dnglobspec/html/ws-security-addendum.asp#ws-security-addendum__toc17425559 at 5.2.1. Expiration.

 

• What is your timestamp expiration set to?  5 seconds? 60 seconds?
• Are the client and server using an NTP server (they need to be at LEAST within 30 seconds of each other or so.
• What times are you seeing?  (What does the “conversation” look like between the two machines...use ProxyTrace or YATT.)
• Are the machines (client and server) set to their respective timezones (in Windows Regional Settings)…some people in New York just change the system time and not the zone and the machine thinks it’s in Tijuana.

It’s may not be an issue of hours apart; it’s probably minutes or seconds from UTC.  Timestamping only works when the clocks are set and set well! :)

UPDATE: in classic CarTalk style it turns out it it WAS the TimeZone.  If you don't tell your system WHERE it is, it can't tell you what time UTC is.

Did you know that you can nest #regions in VS.NET?  You can create hierarchies of regions...seems obvious, but it wasn't to me.  Thanks to Rocco for the tip.

Can't believe I didn't notice this...I'm off to claim my free PocketPC...

We have VS.NET2002 a project that hasn't been updated to VS.NET2003 and logisitically can't for a few weeks.  However, we had a need for a post-build file copy.  It's a large Online Banking project (since we do eBanking here at Corillian) for a very large Financial Institution, so there's lots of people working on the project at once.  Ordinarily the project is built with the increasingly snazzy NAnt so these post-build processes are no biggie.  However, sometimes you'd just like to do stuff from VS.NET. 

We looked the two obvious ways:

• Custom VS.NET Build Rules Add-In:  There's a lovely and simple sample from MSDN in VB.NET with source included.  It cleverly (and rightfully) stores it's config info in the .csproj as an extra XML section.
• Use a C++ MakeFile Project and get it to run last with Project Dependancies:  This was my first, gut reaction, backed up as at least value by Chris Sell's mention of it.  I like it since we wouldn't have to install anything assuming we already had C++ on the box. 

So, between a rock and a hard place, we'll use the Custom Add-In for a few months then upgrade and VS2003.  It's all good.

Win2K SP4 is up and out.  A quote from NTBUGTRAQ:

"Downloads, readmes, etc... all available, not limited to Premier customers, no "Confidentiality" clauses, not June 30th, no broken parts (hmm, have I missed anyone's claim?)"

Go get it...or better yet, get Windows 2003 Server.