>Thanks George. I was just doing some testing along the same lines as you to see if I could find a pattern. I found the same kind of thing you did where Eastern Time (US&Canada) (GMT-05:00) works fine and Indiana (East) (GMT-05:00) causes a crash.
>
>DST sounds like a good guess to me ... it's better than anything I have at the moment. <g> Anyhow, I hope you're able to find something out ... let me know if there's anything I can do to help. Your code will come in really handy for a data synchronization project I'm working on if we can get this sorted out.
>
Rodd,

In reading the Platform SDK, while it doesn't specify that a zero month value of the StandardDate and DaylightDate members of a TIME_ZONE_INFORMATION structure indicates that the area doesn't support DST, it does say that it is a valid value.

In reviewing the code, it appears to be a relatively easy fix. Just evaluate the month value of one of these two members. If it's zero, then have Date_Calc return an empty date/time value. Otherwise, return the appropriate date. I'll probably do some stuff to-day and finish and upload to the UT late tomorrow after some testing.