Quartz.NET – Ce test unitaire ne devrait-il pas réussir?

Cette question est liée à celle-ci , mais rest plus générale et peut être traitée indépendamment.

EDIT: la version Quartz est v2.0.1

De ma compréhension, le test unitaire suivant devrait réussir:

[Test] public void Test() { // run every first day of month at 14:00 hours CronExpression expression = new CronExpression("0 0 14 1 * ?"); // TimeZoneInfo.Local = {(UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien} if (!TimeZoneInfo.Local.SupportsDaylightSavingTime) { return; } // get "summertime" period for current timezone var daylightChange = TimeZone.CurrentTimeZone.GetDaylightChanges(2013); // -> daylightChange.Start {31.03.2013 02:00:00} System.DateTime // -> daylightChange.End {27.10.2013 03:00:00} System.DateTime // get one startpoint before and one after begin of summertime DateTimeOffset beforeSummertime = daylightChange.Start.ToUniversalTime().AddDays(-1); DateTimeOffset afterSummertime = daylightChange.Start.ToUniversalTime().AddDays(1); // -> beforeSummertime {30.03.2013 01:00:00 +00:00} System.DateTimeOffset // -> afterSummertime {01.04.2013 01:00:00 +00:00} System.DateTimeOffset DateTimeOffset? nextValidTimeFromBefore = expression.GetNextValidTimeAfter(beforeSummertime); DateTimeOffset? nextValidTimeFromAfter = expression.GetNextValidTimeAfter(afterSummertime); // nextValidTimeFromBefore {01.04.2013 13:00:00 +00:00} System.DateTimeOffset? // nextValidTimeFromAfter {01.04.2013 12:00:00 +00:00} System.DateTimeOffset? Assert.AreEqual(nextValidTimeFromBefore, nextValidTimeFromAfter); } 

Toutefois, comme vous pouvez le constater, nextValidTimeFromBefore diffère de nextValidTimeFromAfter . Le résultat dans nextValidTimeFromAfter est correct. L’heure UTC 12:00 donnera lieu à 14:00 pendant l’été (qui a déjà commencé à ce moment-là). Peu importe que le paramètre GetNextValidTimeAfter() spécifie une heure à l’intérieur ou à l’extérieur de la période d’heure d’été.

Le NextValidTimes doit-il être égal ou mon approche est-elle défectueuse?

J’ai compris qu’il s’agissait en fait d’un bogue dans Quartz.NET 2.0.1, mais il a déjà été corrigé dans la version 2.1.0.

J’ai vérifié le journal des modifications sur le site, ce qui ne mentionne pas un correctif connexe. Le commentaire de Peter Ritchie m’a encouragé à jeter un autre regard sur les nouvelles versions de Quartz. Quand j’ai regardé à travers les commits dans le référentiel, j’ai remarqué qu’il y avait un correctif pour cela.

Il a été corrigé dans la révision 665:

Fusionner la demande de tir n ° 72 de amazing-andrew / master
Problèmes de fuseau horaire avec CronExpression, calendriers, CalendarIntervalTriggerImpl

La première version officielle contenant ce correctif est la version 2.1.0, qui a été identifiée à la révision 685.

Le bogue se trouvait dans CronExpression.GetTimeAfter() (appelée par CronExpression.GetNextValidTimeAfter() ):

 ... d = new DateTimeOffset(year, d.Month, d.Day, d.Hour, d.Minute, d.Second, d.Offset); // apply the proper offset for this date (this wasn't there) d = new DateTimeOffset(d.Year, d.Month, d.Day, d.Hour, d.Minute, d.Second, this.TimeZone.GetUtcOffset(d.DateTime)); ...