{"push_id":2666933806,"size":1,"distinct_size":1,"ref":"refs/heads/issue_17732_again","head":"a88ccf31db7f4c203c668125842dd67a7fe38e03","before":"267df0c21815a6e2c884f9d8283afef662a7be98","commits":[{"sha":"a88ccf31db7f4c203c668125842dd67a7fe38e03","author":{"name":"Jonathan M Davis","email":"be0932fcbe678439a61c8bd0b747099821fe24ec@jmdavisprog.com"},"message":"Fix issue 17732: SysTime.init.toString() segfaults.\n\nThis adds a special TimeZone type internal to SysTime which _timezone is\ndirectly initialized to so that SysTime.init will work without\nsegfaulting but will still be uniquely identifiable with the is\noperator. Or at least, _timezone is _supposed_ to be directly\ninitialized to it, but issue# 17740 currently prevents that. So,\n_timezone has been temporarily renamed to _timezoneStorage and private\ngetters and setters named _timezone have been added. The getter then\ndoes a null check and returns InitTimeZone() for SysTime.init to\nsimulate the member variable having been initialized to InitTimeZone().\nOnce issue# 17740 has been fixed, these accessors will be unnecessary,\nand the code should be updated so that _timezone is properly a variable\nagain and is directly initialized with InitTimeZone().\n\nThe new TimeZone type - InitTimeZone - is internal to SysTime and can\nonly be obtained by the timezone getter on SysTime.init. It acts the\nsame as UTC except that it is not special-cased by the to*String\nfunctions and thus will print out its timezone as +00:00 instead of z,\nwhich is perfectly legitimate per the spec. And as such, if _timezone\nwere directly initialized with InitTimeZone(), there would be no extra\nchecks due to this change, and everything would just work. However,\nuntil issue# 17740 is fixed, there will be an extra null check any time\nthat a function is called on _timezone, because _timezone is currently a\nwrapper that does a null check rather than being a member variable\ndirectly like it's supposed to be.\n\nUnlike previous attempts along these lines, this does not make it so\nthat SysTime.init has NaN behavior such that any operation (other than\nassignment) on an an uninitialized SysTime would result in SysTime.init,\nand the timezone setter property does not set the SysTime to\nSysTime.init if it's passed this TimeZone. So, unfortunately, it _is_\npossible to have other SysTime values with the special TimeZone, but it\nwas deemed unnecessarily complex for too little benefit to add the NaN\nbehavior. And regardless, SysTime.init is still uniquely identifiable\nvia the is operator. It's just that it can't technically be uniquely\nidentified by the timezone getter, which was never a supported feature\nanyway.","distinct":true,"url":"https://api.github.com/repos/jmdavis/phobos/commits/a88ccf31db7f4c203c668125842dd67a7fe38e03"}]}
{"actor":{"display_login":"jmdavis"}}