Re: DST change issue for timezones in southern hemisphere

[Rich Felker <dalias@libc.org>]

On Wed, Mar 15, 2017 at 03:01:12PM -0400, Rich Felker wrote:
> On Mon, Mar 06, 2017 at 12:44:53PM +0200, JS wrote:
> > Hi!
> > 
> > For some reason DST change in southern hemisphere occurs 1 hour late
> > when clock is turned backward and 1 hour early when clock is turned
> > forward.
> > 
> > For example, timezone for spec for Brazil is:
> > BRT3BRST,M10.3.0/0,M2.3.0/0
> > Which means that DST change occurs at midnight.
> > 
> > Output of date for both DST changes:
> > 
> > ~# date
> > Sun Feb 19 00:59:59 BRST 2017
> > ~# date
> > Sun Feb 19 00:00:00 BRT 2017
> > 
> > ~# date
> > Sat Oct 14 22:59:59 BRT 2017
> > ~# date
> > Sun Oct 15 00:00:00 BRST 2017
> > 
> > I've tested the same code on same hardware but with uClibc library
> > instead of musl and it works fine.
> 
> I think this is indeed a bug. Can you confirm that the correct
> progressions across DST change should be:
> 
> Sat Feb 18 23:59:59 BRST 2017
> Sat Feb 18 23:00:00 BRT 2017
> 
> Sat Oct 14 23:59:59 BRT 2017
> Sun Oct 15 01:00:00 BRST 2017
> 
> If so I think I have a working fix (see attached). The logic for
> handling DST transition times for southern hemisphere was trying to do
> something special that was actually wrong and didn't need to be
> special-cased.
> 
> Rich

> diff --git a/src/time/__tz.c b/src/time/__tz.c
> index 0e0c4ea..ffe8d40 100644
> --- a/src/time/__tz.c
> +++ b/src/time/__tz.c
> @@ -373,18 +373,14 @@ void __secs_to_zone(long long t, int local, int *isdst, long *offset, long *oppo
>  	long long t0 = rule_to_secs(r0, y);
>  	long long t1 = rule_to_secs(r1, y);
>  
> +	if (!local) {
> +		t0 += __timezone;
> +		t1 += dst_off;
> +	}
>  	if (t0 < t1) {
> -		if (!local) {
> -			t0 += __timezone;
> -			t1 += dst_off;
> -		}
>  		if (t >= t0 && t < t1) goto dst;
>  		goto std;
>  	} else {
> -		if (!local) {
> -			t1 += __timezone;
> -			t0 += dst_off;
> -		}
>  		if (t >= t1 && t < t0) goto std;
>  		goto dst;
>  	}

Semantically this seems correct, so I'm applying it. Let me know if
you still find the behavior incorrect.

Thanks for reporting this.

Rich