[Issue 13319] New: tzDatabaseNameToWindowsTZName should return null on failure rather than throw

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13319

          Issue ID: 13319
           Summary: tzDatabaseNameToWindowsTZName should return null on
                    failure rather than throw
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: Phobos
          Assignee: nobody at puremagic.com
          Reporter: jmdavisProg at gmx.com

Currently, tzDatabaseNameToWindowsTZName and windowsTZNameToTZDatabaseName
throw on failure. In most cases, this is fine, because the common usage is
likely to be something like

    auto tz =
WindowsTimeZone.getTimeZone(tzDatabaseNameToWindowsTZName("America/Los_Angeles"));

and having that throw on failure is what we want, particularly since it'll
probably be fed immediately into the constructor for SysTime. However, in the
case where you're trying to check conversions, the fact that it throws is
actually very annoying. So, I propose changing it so that they return null no
failure, and then getTimeZone would throw instead (because it was given null
for the timezone name). So, the normal use case would just get a different
error message on failure.

The only place that I can think of where this change might break code is in
checking for whether a particular time zone conversion exists, because right
now, it would check for whether an exception is thrown, and after this, it
would have to check for null. So, such code could conceivably break, but such
code is also likely very, very rare. So, I woludn't expect much code breakage,
and hopefully the few folks who would be affected would see the changelog and
change their code. But if they didn't, they'd probably still end up calling
getTimeZone with the result at some point and get an exception, since it would
be extremely rare for anyone to need those conversions for something else. So,
it's a risk, but I think that it's small enough that it's acceptable.

--