TZ

[Simon Bowring]

>DOS, OS/2, and Doze, for better or worse (actually, for worse), don't use
>TZ correctly.  That's that.

In this case "That" most certainly is not "that"! 

Just because these (and other OSs) work in local time (not the way 
of unix), doesn't mean they are broken or incorrect! The unix way is 
superior though (in my opinion).

When you consider that DOS, Win and OS/2 originally ran on largely 
standalone machines with little or no networking, and when they did 
use networks it was mainly on a LAN (which tends to be all in the same
timezone).  It is only recently with the rise of WANs including
the mother of all WANs, the internet, that timezones have become 
more of a problem, and even then it only affects few apps (like mail 
and news) when users have incorrectly configured TZ variables.

Sure, I'd prefer OS/2 to work like unix for timezones, 
but it's support is not faulty.

>Programs, such as OD or others, can have a "sensitivity" list (I
>think DragText does that too).  These are programs that are known to
>have problems with interactions.  If that intelligence could be added
>to a new clock driver, with a list of "compatible" apps, the driver
>could return GMT, otherwise, local time.  Granted, this would be a
>royal pain in the patoot, and the program list could be quite long
>(and prone to errors at first).  Short of that, I just don't see any
>way out of this.

This wouldn't be sufficient, the clock drievr has no idea what use
the application is going to use the time for - different calls within
the same app may require different behaviour, and hey, nothing is really 
broken, it just isn't very good (and doesn't work the way people
with unix experience imagine it does).  Putting in a lot of effort to
provide a complex and highly dodgy fix for something that's not 
really broken would be likely to cause more problems than it fixes!
[This is the way of microsoft, intellinonsense, and unpredicatable 
system behaviour!]

Simon