Incorrect DST handling for southern hemisphere?

[mdarnold1]

DST for southern hemisphere timezones does not seem to work correctly.
NTP::summerTime() assumes that utcDST<utcSTD, and NTP::beginDST() assumes both utcDST & utcSTD apply to current->tm_year. Then it follows that NTP::summerTime() always returns false for the southern hemisphere.

[sstaub]

Can you give me an example, maybe you must use a "-" for DST.

[sstaub]

Does it work?

[mtongnz]

I also have this issue using NZ timezone (UTC + 12).

My workaround is to put STD in the DST and DST in the STD:

uint8_t utcOff = 12;
timeClient.ruleSTD("NZDT", Last, Sun, Sep, 2, (utcOff+1) * 60);
timeClient.ruleDST("NZST", First, Sun, Apr, 3, utcOff * 60);

Annoying but works

[mtongnz]

Looking at NTP.cpp, I think it's in the NTP::summerTime() method (line 274).

This is untested but might fix it ??

bool NTP::summerTime() {
	if ((utcCurrent < 0) {
		if ((utcCurrent > utcDST) && (utcCurrent <= utcSTD)) {
			return true;
		}
	} else if ((utcCurrent < utcDST) && (utcCurrent >= utcSTD)) {
		return true;
	}
	return false;
}

[ggatenby]

I also have this issue using NZ timezone (UTC + 12).

My workaround is to put STD in the DST and DST in the STD:

uint8_t utcOff = 12;
timeClient.ruleSTD("NZDT", Last, Sun, Sep, 2, (utcOff+1) * 60);
timeClient.ruleDST("NZST", First, Sun, Apr, 3, utcOff * 60);

Annoying but works

Same workaround appears to work for me as well - will be able to confirm 100% at end of DST in April 2025. I'm in Australia - also southern hemisphere but UTC +10/+11 DST

I agree with @mdarnold1 that the logic is flawed in that in the southern hemisphere DST commences late in one calendar year and ends early in the next, whereas in the northern hemisphere it commences and ends in the same year so as both @mdarnold1
and @mtongnz point out the problem would appear to lie within the logic surrounding NTP::summerTime() method (line 274).

This can be fairly easily proven by changing ntp.ruleSTD("AEST", Last, Sun, Mar, 2, 600) to ntp.ruleSTD("AEST", Last, Sun, Nov, 2, 600) which in effect brings DST end into the same calendar year as DST start which in turn causes the correct offset to be applied

Ultimately though I can't see an easy fix without adding an additional configuration parameter