https://support.microsoft.com/en-us/kb/3148851

This update floated through last night and is now causing the Win_32 tester to fail.  The Win_32_64 will almost certainly start failing as soon as the update makes its way onto that box.

Why are the datetime tests so damned sensitive to external system state?
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On Wednesday, 13 April 2016 at 18:50:31 UTC, Brad Roberts wrote:
> https://support.microsoft.com/en-us/kb/3148851
>
> This update floated through last night and is now causing the Win_32 tester to fail.  The Win_32_64 will almost certainly start failing as soon as the update makes its way onto that box.

Took a stab at it:
https://github.com/D-Programming-Language/phobos/pull/4196

> Why are the datetime tests so damned sensitive to external system state?

Seems like the tests want to make sure that we know how to convert ALL Windows timezone names to their tz database equivalents. Not sure how much sense that makes, however the relevant functions are being deprecated.

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On Wednesday, April 13, 2016 21:03:45 Vladimir Panteleev via phobos wrote:
> On Wednesday, 13 April 2016 at 18:50:31 UTC, Brad Roberts wrote:
> > https://support.microsoft.com/en-us/kb/3148851
> >
> > This update floated through last night and is now causing the Win_32 tester to fail.  The Win_32_64 will almost certainly start failing as soon as the update makes its way onto that box.
>
> Took a stab at it: https://github.com/D-Programming-Language/phobos/pull/4196
>
> > Why are the datetime tests so damned sensitive to external system state?
>
> Seems like the tests want to make sure that we know how to convert ALL Windows timezone names to their tz database equivalents. Not sure how much sense that makes, however the relevant functions are being deprecated.

If we don't test it, we won't catch when the code is wrong due to a change in Microsoft's time zone info. But the fact that it changes so frequently like this is precisely why that functionality has been deprecated in favor of reading the conversion data in from a file, thereby leaving it up to the programmer to make sure that the data is up-to-date. I think that it's quite clear that hardcoding it as I did originally has proven to be a bad idea. Unfortunately, it'll be a while before those functions are done with the deprecation cycle and removed, so we have to continue to deal with Microsoft's random changes until then.

- Jonathan M Davis

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 4/14/2016 9:35 AM, Jonathan M Davis via phobos wrote:
>
> If we don't test it, we won't catch when the code is wrong due to a change
> in Microsoft's time zone info. But the fact that it changes so frequently
> like this is precisely why that functionality has been deprecated in favor
> of reading the conversion data in from a file, thereby leaving it up to the
> programmer to make sure that the data is up-to-date. I think that it's quite
> clear that hardcoding it as I did originally has proven to be a bad idea.
> Unfortunately, it'll be a while before those functions are done with the
> deprecation cycle and removed, so we have to continue to deal with
> Microsoft's random changes until then.
>
> - Jonathan M Davis

I agree that it is something that needs to be caught and adapted for, but I disagree that it's a unit test that should do that.  As a unit test, the impacts are large and disruptive.  As some other tool, it's minimal and still actionable.
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On Thursday, April 14, 2016 11:33:09 Brad Roberts via phobos wrote:
> On 4/14/2016 9:35 AM, Jonathan M Davis via phobos wrote:
> > If we don't test it, we won't catch when the code is wrong due to a change
> > in Microsoft's time zone info. But the fact that it changes so frequently
> > like this is precisely why that functionality has been deprecated in favor
> > of reading the conversion data in from a file, thereby leaving it up to
> > the
> > programmer to make sure that the data is up-to-date. I think that it's
> > quite clear that hardcoding it as I did originally has proven to be a bad
> > idea. Unfortunately, it'll be a while before those functions are done
> > with the deprecation cycle and removed, so we have to continue to deal
> > with Microsoft's random changes until then.
> >
> > - Jonathan M Davis
>
> I agree that it is something that needs to be caught and adapted for, but I disagree that it's a unit test that should do that.  As a unit test, the impacts are large and disruptive.  As some other tool, it's minimal and still actionable.

"Some other tool" would never get run, and the unit tests are doing exactly what unit tests normally do - test that the functions work correctly. The fact that the tests fail as frequently as they do is just a sign that the functions were designed badly. The tests themselves are doing exactly what they're supposed to do.

Regardless, the functionality in question has been deprecated, so it's only a matter of time until it's been removed and won't be a problem anymore.

- Jonathan M Davis

_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos