I experienced a similar problem here with f.lux 4.111 in Windows 7:
I have my earliest wake time set for 10:30 am. Sometime around 1 am PDT f.lux started gradually turning the screen from the sunset tint to the bedtime tint like it normally does. Then a second after 1:59:59 am PDT my computer's clock jumped to 1:00 am PST because daylight saving time had ended. When that happened, f.lux quickly turned my screen from the bedtime tint to a transition color between the sunset tint and the bedtime tint, and then resumed slowly turning it to the bedtime tint. I can reproduce the bug by changing my clock backwards. I also tested for the same bug when daylight saving time starts in the spring, and the bug is there too: f.lux jumps forward suddenly from the transition tint to the bedtime tint when the clock skips 2 am PST and jumps to 3 am PDT. I had to set my earliest wake time to 11:30 to trigger the bug in that test. I restarted f.lux each time I changed my clock for these tests.
The bug is that f.lux is subtracting from the next earliest wake time in the current local time zone instead of in the local time zone that the next earliest wake time will be in. 10:30 am local time on Nov. 3 (local) where I live is PST, not PDT, even if it's PDT and Nov. 3 at this moment. There are several ways of fixing this, but the bottom line is that the earliest wake time should be taken as a local time, and since the time zone isn't attached to the earliest wake time setting, you need to figure out which time zone that local time is in, with consideration for the fact that a local day can have two different time zones on the days that daylight saving time starts or ends. There's also an ambiguous case when the earliest wake time is between 1 am and 2 am on the days that daylight saving time ends, since there are two different 1 am hours on that day, one in daylight saving time and one in standard time.
Honestly this bug is not a huge deal to me. I can live with it. The current behavior at least is easy to understand.