@ Head

while I'm waiting for the huge Orcas images to download, I thought I'd catch up on some blog reading and see if anyone else is talking about it yet.  Surprisingly no-one is *yet*, but give it a few more hours and the bubbling stream should turn into a raging torrent ;)

But I did find one very interesting blog entry.  Kathy Kam has been busy spending time on time, and now we get to see TimeZoneTheSequel TimeZone2.  Yes it took an Aussie to bring the reality of dates to those Americans :)  (you know the ones I mean the ones who put the month ahead of the day in short date formats ;)) 

Of course this is just the beginning, soon we really will be able to represent a precise moment in time

  

You can now download virtual PC images of Orcas September CTP  :)

I listened to Nick Randolph's first podcast the other day and having just read Dave Lem's "review" of it, just seems to highlight to me the very different perspectives.  I think I was listening to it with an open mind and hearing about the issues Nick, Athena and Adam have faced, the approaches they have taken and what worked and didn't work for them.  Dave seems to have heard only problems he apparently already knew ?  Is this a cup half full vs. half empty thing ?  The cynic in me would say it was more Dave was looking for easy fixes to add to his action//todo list.  I think that's insulting though to Dave, Adam, Athena and Nick as I'm pretty sure if they knew the solutions to the problems those kind of people would have already implemented them or been in Dave's ears about them already.  The fact is they showed they managed to get things to work, how they dealt with finding the right schedules, etc. They *are* running successful user groups.  Does that mean that they shouldn't be saying there are problems they don't know the solution to ?  I don't think so, in fact I think that shows that they are constantly looking for ways to make things better.

 

So please, let's not insult those dedicated people who give so much to the community because they are open and honest enough to talk about issues they and their communities face.  and please let's not insult them by insinuating they have the solutions and have been holding back.  Rather lets listen and say thanks :)

 

Thanks Nick, Athena, and Adam

 

 

This year sure is shaping up as a warm and dangerously dry year.  I had fruit trees blooming at the start of August ( a record for me), and now the fire season has started already, two months before restrictions even come into force.

 

Yesterday we got called to assist with a small fire, then upon leaving there inspected another fire, and then got  an emergency call to yet another fire.  The Yeodene fire was 60 hectares, 22 appliances in attendance, including one small helicopter and one fixed wing observer.  The strong winds had driven the fire down a gully into some serious bush.   Amazing to see the fire so fierce this time of year. Luckily a change came near dark fall, and the cooler moist air helped make it easy(ier) to bring under control.

 

hopefully we'll see lots of rain through-out summer, but that's not what some of the weather folk are saying.  :(

 

 

If you install Microsoft Expression Web Beta 1 on a system with Microsoft Outlook 2003, you may find that the junk mail is not being moved  to the junk mail folder.  This is a known problem. 

 

To fix:

 

- open Add/Remove programs,

- ensure the little check box at the top "show updates" is checked

-scroll down till you see Microsoft Office …… and then find the latest outlook junk mail entry under that e.g. "Update for Outlook 2003: Junk E-mail Filter (KB920907):OUTLFLTR"

- remove that

- reboot.  this may be optional, but I would just to be safe :)

- run a Microsoft Update and re-install the Outlook Junk E-mail filters

 

 

 

 

Get the .NET 3.0 Visual Studio bits (aka Cider and WF).  Don't get confused about the Orcas naming, it's not really Orcas as it doesn’t include LINQ,

it is  .NET 3.0 tools for Visual Studio 2005 in my speak ;)

 

You'll need a version of VS 2005 of course and the recently released .NET 3.0 Release Candidate 1

 

 

enjoy :)

Kathy Kam asks if we should modify DateTime or create a new type to store time zone information.  I say give us a new type. My reasons are:

 

DateTime in .NET is a pretty high precision (100 nanosecond resolution) storage, using most of the 64 bits.  In .NET 2.0 they took a couple of the upper most bits of DateTime's 64 bits to indicate if the time was local, UTC, or unspecified. (a non breaking change).  But to store accurate representation of the time zone, and/or the offset then you'd need a lot more bits.  Time zone as an abbreviated string is going to take at least 3 or 4 bytes (32 bits gone).  Offset has to allow for minutes, (+- 720), so that's another 27 or so bits.  So that leaves us 5 bits to store the actual value in… I don't think so.

Reality is, a TZDateTime would require probably a full 128 bit to retain the precision DateTime currently has.

This has two significant issues, breaking code, and performance.  If you have any code that is reliant on the in memory size of a structure (or class) that has DateTime fields, then that code is seriously broken. You'd have to replace the DateTime with an Int64. however the likelihood of such code is in fact rare, as most code reliant on such structure layout is PInvoke centred code, and Win32 API typically uses different date storage mechanisms (such as Ole Date which is 8 bytes but a float)

The performance issue would remain though and maybe an overhead if you are doing a lot of date time crunching.

binary serialization : you're broken.

 

 

But apart from the size of the structure, the big issue I think is how simple will the code be.  At first you might say having two types is more complicated, but you need to consider the transition.  Do you really want to always be checking to see if the DateTime has it's time zone set ?  how will you know if it's an old style date, or a new style one ?  How will you tell if the code around that date structure has been updated to persist, and pass the time zone with it, or is the old code ?

 

 

On the other hand, a new type poses many issues.  It would require new types and support for data storage.   Hang-on, that's a good thing though isn't it, as this way we can ensure integrity of data. The cost though is it isn't simply adding one type to the framework, rather it's an issue of providing a mesh of supporting types and methods.

UI controls would also need to be updated, but perhaps a different DateTime picker is better than breaking the behaviour of the existing one ? Either way, it would require work on the DateTime pickers which is probably a good thing as we'd hope the next incarnation would also support nullable TZDateTime's as well :)

And we'd probably also need an implicit conversion from DateTime to TZDateTime, but preferably an Explicit conversion from TZDateTime to DateTime.

 

Anyway, I'm probably drifting off into more the functionality I'd like to see the new timezone aware DateTime structure have (such as overloads on Add, that let you specify whether or nor to take DST transitions into account <g>).  My general feeling is this is a new type, with many new features. If DateTime was not a structure I would say inherit DateTime.  It's a pity there isn't an interface the two could share (hint hint).  But I think with the implicit casting to DateTime from the new structure, you could call existing code reasonably easily, and the potential loss of data (TZ offset) would be more obvious due to the explicit cast needed to bring the data back.  If it was just the same structure, I don't think you'd ever know if the routine was likely to loose data or not.. the complexity of the type and it's safe and proper usage would be too high.

 

So my vote is for a new data type, TZDateTime (or DateTimeTZ)