https://issues.dlang.org/show_bug.cgi?id=17740
--- Comment #2 from Jonathan M Davis <issues.dl...@jmdavisprog.com> --- Well, it looks like it relates to directly assigning a non-null value to the _timezone member at compile time. The new TimeZone class declaration is not required. All you have to do to trigger it is to change line # 8996 at the bottom of std.datetime.systime from Rebindable!(immutable TimeZone) _timezone; to Rebindable!(immutable TimeZone) _timezone = UTC(); Unfortunately, declaring a struct like struct S { Rebindable!(immutable TimeZone) _timezone = UTC(); } does not exhibit the problem. So, I don't know how to create a small test case that doesn't require the std.datetime code. But assigning UTC() like this before used to work. A backend bug on Windows prevened me from getting a similar PR merged where it added a new TimeZone class, and assigning UTC() in that case had exactly the same problem as I recall (certainly, assigning the new time zone class did, because that's what blocked the PR). But it worked perfectly fine on other OSes, and I'm fairly certain that I tried those changes again at some point, and the backend bug was gone - I just wanted to rework the changes, so they weren't committed. Regardless, it worked perfectly fine on non-Windows OSes previously. So, something about this broke in the last several releases. I'd have to do some research to figure out when it broke though. --