Rockford Lhotka

 Thursday, March 31, 2005

I just spent three days getting inundated with the details of Indigo as it stands today (in its pre-beta state). For those that don’t know, Indigo is the combined next generation of .NET Remoting, Enterprise Services, Web services (asmx and WSE) and MSMQ all rolled into one big ball.


I also had some conversations about Avalon, though not nearly in so much detail. For those that don’t know, Avalon is the next generation display technology that uses full 3D rendering and should allow us to (finally) escape the clutches of GDI. Avalon is the display technology related to XAML. XAML is an XML markup language to describe Avalon interfaces.


My interest in these technologies spans quite a range of concerns, but top on my list is how they might impact my Business Objects books and the related CSLA .NET framework.


It turns out that the news is pretty good. Seriously good actually. In fact, it looks like people using CSLA .NET today are going to be very happy over the next few years.


Within the context of CSLA .NET, Indigo is essentially a drop-in replacement for Remoting. I will have to change the DataPortal to use Indigo, but that change should have no impact on an application’s UI, business logic or data access code. In other words (cross your fingers), a business application based on CSLA .NET should move to Indigo with essentially no code changes.


[Disclaimer: Indigo isn’t even in beta, so anything and everything could change. My statements here are based on what I’ve seen and heard, and thus may change over time as well.]


One of my primary goals for CSLA .NET 2.0 is to alter the DataPortal to make it easier to adapt it to various transports. In the short term this means Remoting, asmx, WSE and Enterprise Services (DCOM). But it also means I’ll be able to add Indigo support with relative ease once Indigo actually exists.


Avalon is a different story. Avalon is a new UI technology, which means that moving to Avalon means tossing out your existing UI and building a new one. But if you are using Windows Forms today, with CSLA .NET business objects for your logic and databinding to connect the two together your life will be better than most. It appears that Avalon will also support databinding against objects just like (hopefully better than) Windows Forms.


Since a well-written CSLA-based Windows Forms application doesn’t have any business logic (not even validation) in the UI itself, switching to Avalon should merely be a rip-and-replace of the UI, with little to no impact on the underlying business or data access layers. I keep telling people that the “UI is expendable”, and here’s the proof :-)


I just thought I’d share these observations. Indigo and Avalon (together under the label of WinFX) won’t show up for quite a long time, so none of this is of immediate interest. Still it is nice to know that when it does show up sometime in the future that CSLA .NET will have helped people to move their applications more easily to the new technologies.

Thursday, March 31, 2005 11:10:08 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Cross-pollination is one of the benefits of regular interaction with fellow speakers and authors. For instance, Juval Lowy was just showing me this cool and rather obscure feature where you can just make method calls “disappear”. Now I am not convinced that this is a good thing, as the effect is not at all explicit or obvious – but it is cool nonetheless.


The idea is that you can write a method:


Public Sub Foo()

End Sub


Then you can call this method elsewhere in your code. Perhaps even many places in your code:


Public Sub Client()


End Sub


So far so good. But now apply this attribute to the Foo method:


<Conditional("MyFlag")> _

Public Sub Foo()

End Sub


When you now compile your project, Foo is compiled, but the call to Foo in the Client method is not included in the result. Yes, that’s right – all calls to Foo everywhere in your code disappear without a trace. They aren’t in the CIL, and thus are just poof, gone.


To get those calls to Foo back, you need to define a compiler symbol:


#Const MyFlag = True


Now mystically, the calls to Foo will reappear in the compiled code.


This is a form of conditional compilation, similar to checking for a debug condition or something. But it is not explicit, and the caller will have no idea that they aren’t calling the method any more. Nor will the developer, since there’s no way for the caller to even know that the method is marked for disappearance.


Seems like a feature that should remain obscure, but from a purely geeky perspective it is pretty interesting.

Thursday, March 31, 2005 10:56:10 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I am a proud signatory of the petition to save IDL. Some may consider such petitions to be foolhardy, even absurd, but I think it is important to put forth some effort to save endangered technologies such as IDL. To see something this important, this transformative and this intuitive simply fade away into obscurity would be a terrible fate.


Wait! What the hell am I saying? I hate IDL! Hey, how do I unsign that damn petition anyhow? Damn! Now like numerous VB6 developers, I have signer’s remorse… Woe to me!

Thursday, March 31, 2005 10:45:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, March 27, 2005
Bill Vaughn and I were recorded live at Dev Connections in Orlando for a .NET Rocks interview. As always, .NET Rocks is a whole lot of fun, and recording live is even more fun, so check it out!
Sunday, March 27, 2005 8:44:29 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, March 26, 2005

I was recently asked what I thought about proprietary vs “open” programming languages.


First off, I am not convinced that there is such a thing as an “open” language. Perhaps C and C++ (through the existence of things like GCC). But really the question is whether a language is standards based or not. “Open” is far less important in this regard than being based on a published standard.


The only mainstream languages today that are standards based are C++ and C#. Both VB and Java are proprietary, though of the two Java is arguably more "open".


My concern has never been about whether a language was proprietary or not, but rather whether it was well-supported by both vendors and a community. It is longevity that is important, not openness. Companies build software using languages, and they want to have some confidence that the language will exist longer than their software.


No successful language (proprietary or not) changes frequently/radically and lives long. Similarly, no language that fails to evolve over time lives long. These things are not a function of openness, but rather are a function of support from vendors and community.


VB, for instance, is proprietary, but is the most widely used language in the world. There are more lines of VB out there than of COBOL (which was the previous "king"). It enjoys strong vendor and community support. Witness the incredible effort (and pain) involved in the language’s evolution to the .NET platform. The level of vendor commitment required to make this huge change is not to be underestimated.


C++ is a standards-based language, which means that each vendor comes somewhat close to implementing the standard. There are (to my knowledge) no C++ compilers that entirely meet all standards requirements. But in striving for compliance, there is a high degree of consistency between C++ compilers and for some types of code that can be valuable. Certainly there is strong vendor and community support for C++ since the current mainstream operating systems are written in this language.


C# is also standards-based. Microsoft presumably implements the standard directly, while mono goes beyond it by already adding non-standard features coming in .NET 2.0. One would hope that the C# standard will change to include things like generics, but at present Microsoft is going to be making their C# non-standard in .NET 2.0. Regardless, there is strong vendor and community support for C# both inside and outside Microsoft.


Java is proprietary, with some arguable elements of being "open". Regardless of anyone’s personal or political views on Java, it is clear that it enjoys substantial vendor and community support. It continues to evolve through both open source and vendor initiatives and is a widely used language in many fields.


Each of these four languages has strengths and weaknesses. Features that are missing or sub-par and features that are really cool.


But most important is that all four languages have substantial vendor support and investment. It is clear that none of them will be abandoned by their vendors in the foreseeable future (even C++, which has faded dramatically due to pressure from Java and C#).


Similarly, it is clear that all four of them have vibrant and active community support. You can easily find paying work, code repositories, open-source projects, tools, user groups, conferences and other forms of activity for any of these four languages. If you are more business-focused, there’s a lot of Java work out there, and there’s a lot of .NET work (roughly split 50/50 between VB and C# at present). If you are more hardware-focused there’s still a lot of C++ work to be had. While it is thankfully fading from the business world, C++ remains the dominant language in use by computer engineers and operating system developers.


Of course even with all this, widely used languages never really “die”. This is why there’s a workable market for commercial .NET versions of things like COBOL and FORTRAN. This is why you can still find active development in FoxPro, and why there’ll be active work in VB6 for many years to come. I wrote earlier with some thoughts on the longevity of “dead” technology.

Saturday, March 26, 2005 12:05:54 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, March 21, 2005
I guess I'm famous now, as I've been referenced (and incorrectly corrected) by the Scobleizer :)
Of course Robert didn't realize that it isn't me that is confused about whether XAML is a web technology, but rather it's the people who send me emails about it that are often confused.
Microsoft started this confusion last year at the PDC when they said that XAML was a way of bring the web programming model to Windows. What a stupid thing to say. Not that it is inacurate, but what a whole lot of people HEARD was "XAML is a way to program for Windows and the web at the same time in the same model".
Thus, I (and I'm sure other Microsoft-related people) constantly get questions about how XAML is different from HTML, and what kind of browser will parse it, and why is Microsoft doing this if it can be so easily replicated and so on and so forth.
I suppose I should have been more in my original post regarding the point I was trying to convey. Specifically the point is that XAML is not a web technology other than in that it uses HTTP to deploy code to clients. I thought that was rather clear given that the XAML is compiled to a .NET assembly on the server, and only that assembly goes to the client, but now it should be very clear.
Robert is right though - XAML doesn't impact reach-oriented scenarios much at all on the surface. Organizations trying to project a web presence to everyone in the world will still using HTML.
However, I hold out hope that some higher-profile sites might offer alternate XAML presentations as well - just like some sites offer both HTML and Flash presentations today. I really can see value to someone like Amazon in providing a truly rich user experience as an alternative to the comparatively bland HTML. Another modern example is Napster, which has an adequate HTML interface, but where most people use the rich Windows client. Just think what they will do with XAML/Avalon when it is available!
Monday, March 21, 2005 5:21:30 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

As I’ve mentioned before, I personally like using VB. I tolerate, and have become quite competent in, C#.


But the current situation is frustrating.


I am speaking at an event in a couple months, and the organizers requested that all code samples be in both VB and C#. On one hand this makes sense, but I must say that it means I’ll likely have half the demos I’d otherwise use.


Porting VB to C# or visa versa is boring work. It is time wasted redoing something that’s already done. And I don’t do it. I already have more cool ideas than I have time to try out, and wasting time adding or removing semicolons from my last cool experiment merely cuts into time when I could be doing something interesting.


The sole exception to this is CSLA .NET. In that case I have chosen to maintain two identical versions of the code. It is painful and frustrating, but important. The most frustrating part of it though, is that I have numerous enhancements to CSLA .NET that I’ll never publish to the world, because the pain involved in porting to the other language is too high.


From time to time people have suggested that I use a tool to convert the code. But I opted specifically against that option with CSLA .NET because I wanted the VB code to look like VB and the C# code to look like C#. Code conversion tools don’t capture the subtle stylistic differences between languages, and I consider those differences to be important.


You can always tell VB code that came from such a tool. It looks like crap, and no self-respecting VB developer would ever write such poor code. Likewise, I have no doubt that comparable C# code would be equally offensive.


Since the code I’m talking about here is intended to teach programming concepts, the quality and style of the code is even more important than normal. Thus I just can’t see how using tools of this nature is good.


Perhaps we’ll find out. If I can find a good VB->C# converter maybe I’ll convert some of my demos for this upcoming event and see if the C# attendees howl… (and visa versa)


But I can’t say I’m going to invest a huge amount of time figuring it out, because I’ve got some other cool ideas I’m working on and can’t afford the distraction.

Monday, March 21, 2005 1:31:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, March 18, 2005
Scott and Rory are nuts! Microsoft marketing could learn a thing or two from these guys :)
Friday, March 18, 2005 10:05:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, March 11, 2005

I was going to stay out of this, really I was. But it appears to be spinning out of control, with the press jumping in and spouting inaccurate conclusions left and right…


I am a Visual Basic MVP, and I do not favor the idea of merging the VB6 IDE into Visual Studio 2007 (or whatever comes after 2005). I’m afraid I see that as a ridiculous idea, for many of the reasons Paul Vick lists.


I’ve been in this industry for a reasonable amount of time – nearly 20 years. Heck, my first job on the VAX was porting code from the PDP-11 to the VAX. But there were still companies running that PDP-11 software ten years after the hardware was no longer manufactured.


The lesson? Companies run old, dead technology.




Because it works. Companies are nothing if not pragmatic. And that’s OK. But none of those companies expected DEC to support the long-dead PDP. They built their own support network through user groups and a sub-industry of recyclers who sold refurbished parts for years and years after nothing new was made.


VB6 today is the PDP-11 of 20 years ago. It is done, and support is ending. (though technically Microsoft has support options through 2008 I guess)


And you know what? Companies will continue to run VB6.




Because it works. Microsoft would prefer if you upgraded, but you don’t have to. And that’s OK. But like the people running the PDP-11’s, you can’t expect Microsoft to support a dead tool. Especially when they’ve provided a far superior alternative in the form of VB 2005.


If you want to keep running VB6 that’s cool. But like anyone using dead technology, you have to accept the costs of handling your own support. Of getting “refurbished” parts (in this case developers and components).


I’ll bet you that none of those old companies are still running a PDP-11 today. Why? Because eventually the cost of running a dead technology outweighs the cost of moving forward. The business eventually decides that moving forward is the cost effective answer and they do it.


This will be true for VB6 as well. It is simply a cost/benefit decision at a business level, nothing more. For some time to come, it will be cost-effective to maintain VB6 code, even though the technology is dead. Eventually – perhaps even 10 years later – the cost differential will tip and it will be more effective to move to a more modern and supported technology.


Other than a few odd ducks, I very much doubt that most developers would choose to continue to use VB6. Certainly they wouldn’t make that choice after using VB.NET or VB 2005 for a few days. I’ve seen countless people make the migration, and none of them are pining for the “good old days of VB6” after using VB.NET. Mostly because VB.NET is just so damn much fun!


And if you press the VB6-focused MVP’s, by and large you’ll find that they are staying in VB6 for business reasons, not technical ones. Their customer bases are pragmatic and conservative. Their customer bases are still at the point where the cost of running a dead technology is lower than switching to a modern technology. And that’s OK. That’s business.


What irritates me is when people let emotion into the discussion. This shouldn’t be a dogmatic discussion.


It is business, pure and simple! Deal with it.

Friday, March 11, 2005 2:54:39 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

OK, I am happy!


For years now it has been clear that the patent system is woefully inadequate when it comes to software and software-related patents. Any system that grants a patent for clicking once on a button to buy a product is insane!


Microsoft is far from the worst player in the patent system. IBM files for more patents than you can shake a stick at, and there are many other examples of egregious or opportunistic patents in the software and Internet space by many companies.


However, Microsoft recently has been under fire for Patent # ‘959 (“IsNot”). This is a patent they applied for and which has not yet been reviewed or granted, so it is still pending. The patent is basically for a VB version of the C-style != operator and thus is obviously pretty silly (sorry Paul and Amanda, but it is).


Microsoft is well within their rights to file the patent, and I give it good odds of being accepted (given the track record of the patent office). Given the current state of the patent system, Microsoft has to apply for patents like this – as do all companies. It is pure self-defense. It is really not the fault of the companies that the patent system is messed up…


The result of this patent application has been substantial discussion by Microsoft and various Microsoft “insiders”. My contention all along has been that the patent system needs reform and that Microsoft is a perfect candidate to lead the charge.


And wouldn’t you know it, here they go! Microsoft is actively lobbying for patent reform and has a cohesive list of ways they think the system should change to fix current issues.


I am sure this will lead to some healthy debate (and probably some unhealthy debate by various fools out there) about exactly what should change and how. But the fact that Microsoft is helping to spearhead the debate, to push it to the forefront so it can be discussed is very exciting.


Assuming Microsoft follows through and continues to sincerely push for reform, and participates in the ensuing debate in good faith then I say kudos to Microsoft!

Friday, March 11, 2005 10:29:50 AM (Central Standard Time, UTC-06:00)  #    Disclaimer

I got this email based on a previous post on browser vs rich clients:


I read your comments about smart clients and Google maps. What do you think about XAML + Avalon, is it the MS’s recipe to kill HTML browser? I don’t see how it is a strategic advantage for MS, it is a replicable technology, I bet open source groups will come up with a Mozilla plug-in that is interoperable with that standards.


This question stems from a common misconception, which is that XAML is similar to HTML and is sent to the client where it is parsed and run.


In reality, XAML never leaves the server. It is compiled on the server into a .NET assembly, and that assembly is downloaded and run on the client. While this is replicable, it isn't the trivial task some people think it is.


Either you would need to replicate the .NET runtime and DirectX on the client so you could run the compiled assembly, or you'd need to build a XAML compiler on the server that generates a downloadable executable code module for your platform.


For instance, one could envision a XAML compiler that created some sort of compiled code module that could run on Linux, using OpenGL or some other 3D graphics library on that platform. But this is a non-trivial task, since XAML is designed with the assumption that the target platform has the .NET runtime and DirectX, so the compiler would need to map all the .NET and DirectX functionality into equivalents on some other target platform.


More realistically, you might envision something like mono being extended with Avalon support so it could run the pre-compiled .NET assemblies on non-Windows platforms. Even this is very non-trivial, since they’d have to not only replicate Avalon, but mediate the differences between DirectX and OpenGL or some other graphics library.


There are a couple examples of similar technologies available today. Most notably OpenLazslo and Xamalon. They illustrate the basic concept involved, which is to compile the XML into a binary, which is then transferred to the client and executed.

Friday, March 11, 2005 10:12:11 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, March 9, 2005

I have this long-standing theory and thought I’d share it. The theory goes like this:


First there was DOS.

Then there was Windows which ran on DOS.

Then DOS was emulated in Windows.

Then there was .NET which ran on Windows.

Then Windows was emulated in .NET.


Of course that last bit hasn't happened yet, but I expect it is just a matter of time before Microsoft's OS becomes .NET and Win32 becomes an emulated artifact. I also expect that branding-wise Windows will remain the foremost brand. I think this is why the .NET brand is already being deprecated. .NET as a brand must fade so it can be reborn like the phoenix in the future - as Windows.

Wednesday, March 9, 2005 8:57:24 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, March 7, 2005
Pat Helland has decided to leave Microsoft for Amazon. Pat is an incredibly bright man and is one of the foremost thinkers in the SOA space. I hope he is able to continue to contribute to the space in his new role. In any case - all the best Pat!!
Monday, March 7, 2005 1:45:10 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Here's a very astute article that highlights the reason Linux is virtually doomed to the same fate as Unix.


Years ago, before Microsoft was a serious company and I was still working on VAXen it was clear that Unix was in trouble. We all called it "Unixification" - the reality that each Unix vendor had to differentiate and to differentiate they had to vary from the "standard" and as they varied from the standard they created tiny little niche products that couldn't compete with each other, much less things like the VAX or AS400.


This is the core flaw with any standards-based product concept. If a product is standards-based then all products are the same, so the only way to compete is on price, service and maybe quality (though if the standard is any good then quality should be automatic). Any business person will tell you that this is a commodity market and very few people want to play in the commodity space because it is hard work for low margin.


How do you break out of a commodity market? By de-commoditizing your product. By making it unique and compelling. Hence Unixification. The making of Unix variants that are unique and compelling.


It should come as no surprise to anyone that the efforts to make money of Linux would give rise to the Unixification of Linux. Dare we say "Linuxification". Linux vendors don't want to be stuck in a commodity market any more than their Unix predecessors. The only way out is to de-commoditize Linux - to provide non-standard value-add in substantial ways.


Judge Jackson hit the nail on the head years ago in the Microsoft monopoly trial. He pointed out quite clearly that there is a natural monopoly in the operating system space. In short, there will be a monopoly in the OS - the only question is whether it is Windows, the Mac or a Linux variant.


It doesn’t surprise me at all that people are starting to recognize that the same economic forces that caused Unixification are now causing Linuxification. Ultimately this, coupled with Judge Jackson’s observations about the natural monopoly in this space are likely to ensure that Microsoft retains the dominant desktop OS in the foreseeable future.
Monday, March 7, 2005 1:30:23 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

This past weekend I spoke at two events in Milwaukee, WI.


On Saturday morning I spoke at Deeper in .NET, a local event organized by the Wisconsin .NET user group. They lined up sponsors, got a venue and had around 400 people show up for the free all-day event. The speaker line-up was pretty compelling, including Scott Guthrie and Rob Howard. I was impressed by the organization of the event and I think it was a great day!


In particular I’m very happy to see events like this and the Heartland Developers Conference (in Iowa) be so successful. Typically the big Microsoft conferences are on the coasts – San Francisco, Orlando and so forth. While those are nice destinations, the fact is that we here in the middle of the country want the same content, the same speakers. Events like this one on Saturday bring the speakers and content to the audience, and that is an awesome thing!


Personally though, I think those of us in Iowa, Wisconsin and Minnesota should organize the events in May, June or September. Organizing these events when the weather is cold just reinforces people’s misguided perception about this part of the US. During the months of May, June and September the weather (at least in Minnesota) is as nice as you’ll find anywhere. Probably nicer. And Minnesota is beautiful in those months, all green trees and blue water.


On Friday and Sunday I spoke at the No Fluff, Just Stuff Software Symposium (NFJS). This conference is different from any other I’ve done, and I think is somewhat unique in general.


What makes NFJS unique in general is that they cap attendance at 200 people, they do many shows around the country (so one is probably near you) and they do the shows over a weekend. Basically they are trying to keep it small, intimate and affordable. People must like it, since most shows apparently sell out. Basically they are doing (on a commercial level) what Deeper in .NET and Heartland Developers Conference have been doing via user groups.


NFJS has historically been a Java show, but they recognize that most organizations today use a mix of Java and .NET. They also recognize that the two platforms are more similar than they are different. Because of this, the NFJS organizers are building a .NET component to the conference.


I must say I went with some trepidation, since not all Java people are tolerant toward anything Microsoft (I’m being polite here). But I had a blast. Sure there were a couple misguided sneers here and there, but by and large the people attending the show are serious technologists who want to do the best job they can with the best knowledge and tools they can find. And that kind of person is really fun to talk with irregardless of their preferred development platform!


What I found most interesting about the NFJS attendees is their focus. In a Microsoft conference the focus is all on Microsoft. What is Microsoft going to do, what are they doing and why’d they do what they did? The NFJS show isn’t vendor-focused though, so the attendees were more interested in industry trends rather than vendor actions. People wanted to know where the industry would be in five years, what is going to replace Java now that it is old and boring (Ruby and Groovy seem like popular options), what is the real story about integration between BEA, IBM and yes, even .NET.


There were discussions about whether software development is art or engineering or both (thanks to a keynote by Dave Thomas). But I can’t remember a conference where there was serious debate about whether software is trying to model the real world or is a mathematical proof of a process. The geek-o-meter at this show is very high! :)


I’m doing at least a couple more NFJS shows in Boston and Minneapolis (here’s my speaking schedule), and I’m really looking forward to them!


For user groups interested in organizing day-long events like Deeper in .NET, I strongly recommend it. You can work with your local Microsoft DE, and local consulting and technology companies to get sponsors to cover the cost. Get involved with INETA, as they can help you get speakers (they covered the cost of getting me to Milwaukee for instance). Make it happen – these events are great!!

Monday, March 7, 2005 9:05:57 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, March 2, 2005
In this case he gave it up because he's never worked with Microsoft tools and wasn't about to broaden his horizons and see if they were any good. He even draws a conclusion about what it is like to use Microsoft's tools after having not used them. Presumably a conclusion based on extensive propaganda, since by his own admission it isn't based on actual experience or facts.
Yes, he's a fool, but not because he gave up steady work or good pay. He's a fool in the same way someone who only uses one programming language is a fool. This is the same type of thinking that led to separate black and white drinking fountains in Alabama...
I spent many years on VAX computers, but always had my trusty Amiga nearby. Today I work on Windows with Microsoft tools, but I also run a Linux box, and have worked on Unix boxes off and on my entire career. I also spent tiny bits of time using a PDP-11, a mainframe, an AS400 and a Prime. Heck, I even have Eclipse and several versions of the JDK all set up on my machine.
If all you know is one platform and tool set then your perspective is waaay skewed. Seriously, live a little!
Is it really that scary to think about spending a few months working with Microsoft tools? To see what they are like if nothing else? Eclipse is busily emulating Visual Studio - wouldn't it be nice to know what they are emulating and why?
This isn't about the steady work or paycheck, this is about professional growth. This is about being all you can be by understanding all you can understand.
Ultimately, Moe Taxes cut off his nose to spite his face. He has my pity.
Wednesday, March 2, 2005 4:18:52 PM (Central Standard Time, UTC-06:00)  #    Disclaimer