[9fans] dst shift is shifty

[9fans] dst shift is shifty

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

Am I the only person still an hour behind the PST->PDT shift?
I recall this happening last year, too ...

[9fans] dst shift is shifty

[erik quanstrom]

On Fri Mar 25 17:48:43 EDT 2011, lyndon at orthanc.ca wrote:
> Am I the only person still an hour behind the PST->PDT shift?
> I recall this happening last year, too ...
> 

i thought i fixed the timezone files a couple of years ago.  

ladd; date
Fri Mar 25 18:07:09 EDT 2011
ladd; timein US_Pacific
Fri Mar 25 15:07:23 PDT 2011

did you not copy the new US_Pacific to /adm/timezone/local?

- erik

[9fans] dst shift is shifty

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> did you not copy the new US_Pacific to /adm/timezone/local?

Being in Canada_Pacific, no.  I see an update is required.

[9fans] dst shift is shifty

[erik quanstrom]

On Fri Mar 25 18:54:59 EDT 2011, lyndon at orthanc.ca wrote:
> > did you not copy the new US_Pacific to /adm/timezone/local?
> 
> Being in Canada_Pacific, no.  I see an update is required.

hmmm.  iirc, i made the us change when the law in canada was
in doubt.  sorry for falling down on the job.

as a hack, if you copy US_Pacific, except for the dates from 1973-1974,
that should be the right temporary fix

; diff -c /n/sourcesdump/2006/0401/plan9/adm/timezone/US_Pacific US_Pacific
/n/sourcesdump/2006/0401/plan9/adm/timezone/US_Pacific:1,6 - Canada_Pacific:1,6
  PST -28800 PDT -25200
     9943200   25664400   41392800   57718800   73447200   89168400
-  104896800  120618000  126669600  152067600  162352800  183517200
+  104896800  120618000  136346400  152067600  167796000  183517200

i'll submit a patch.

- erik

[9fans] dst shift is shifty

[erik quanstrom]

>> did you not copy the new US_Pacific to /adm/timezone/local?
> 
> Being in Canada_Pacific, no.  I see an update is required.

i tried to send this off-list, but your zone has no mx record.
sorry to the rest of the list for spam.

anyway, lyndon could you check the timezones in
/n/sources/contrib/quanstro/timezone/tz/Canada_*
to make sure i haven't made any silly mistakes?

will submit if you approve.

- erik

[9fans] dst shift is shifty

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> i tried to send this off-list, but your zone has no mx record.
> sorry to the rest of the list for spam.

And I tried a direct reply, but your MTA is convinced orthanc.ca has
no MX record.  Which is odd since it most most certainly does.  I've
noticed ndb/dns has been acting oddly lately, though.  For the last
couple of months my CPU server has been complaining that
ftp.rfc-editor.org has a malformed IP address while my terminal has no
issue with it.  It hasn't been annoying enough to track down since I
have a workaround, but something weirde is going on here ...

> anyway, lyndon could you check the timezones in
> /n/sources/contrib/quanstro/timezone/tz/Canada_*
> to make sure i haven't made any silly mistakes?

Attached is a trivial timezone file dumper I wrote this morning before
the benefit of coffee.  When I examine the output of runs against
*_Pacific (the system's and Eric's new Canada_*) it strikes me that
the time shifts are happening at UTC time rather than the local
timezone offset.  E.g., here is a sample of
/adm/timezone/Canada_Pacific:

                         PST	                         PDT
Sun Apr 26 02:00:00 GMT 1970	Sun Oct 25 01:00:00 GMT 1970
Sun Apr 25 02:00:00 GMT 1971	Sun Oct 31 01:00:00 GMT 1971
Sun Apr 30 02:00:00 GMT 1972	Sun Oct 29 01:00:00 GMT 1972
Sun Apr 29 02:00:00 GMT 1973	Sun Oct 28 01:00:00 GMT 1973
Sun Apr 28 02:00:00 GMT 1974	Sun Oct 27 01:00:00 GMT 1974

Should these not be taking place either seven or eight hours later
according to GMT?  (I.e.  0200 PST, 0200 PDT) Am I misinterpreting the
values in the timezone files?

--lyndon

-------------- next part --------------
#include <u.h>
#include <libc.h>
#include <stdio.h>

struct tz {
	int offset;
	char zone[5];
};

static char EPARSE[] = "parse error";

void main (int argc, char **argv)
{
	struct tz tz[2];
	Tm *t;
	long i[2];
	int rc;
	char *s;
	
	rc = scanf("%s %d %s %d", &tz[0].zone, &tz[0].offset,
				&tz[1].zone, &tz[1].offset);
	if (rc == EOF || rc != 4) {
		exits(EPARSE);
	}
	printf("%28s\t%28s\n", tz[0].zone, tz[1].zone);
	for (;;) {
		rc = scanf("%ld %ld", &i[0], &i[1]);
		if (rc == EOF) {
			exits(0);
		}
		if (rc != 2) {
			exits(EPARSE);
		}
		t = gmtime(i[0]);
		s = asctime(t);
		s[28] = '\0';
		printf("%s\t", s);
		t = gmtime(i[1]);
		s = asctime(t);
		s[28] = '\0';
		printf("%s\n", s);
	}
	exits(0);
}

[9fans] dst shift is shifty

[erik quanstrom]

> Attached is a trivial timezone file dumper I wrote this morning before
> the benefit of coffee.  When I examine the output of runs against
> *_Pacific (the system's and Eric's new Canada_*) it strikes me that
> the time shifts are happening at UTC time rather than the local
> timezone offset.  E.g., here is a sample of
> /adm/timezone/Canada_Pacific:
> 
>                          PST	                         PDT
> Sun Apr 26 02:00:00 GMT 1970	Sun Oct 25 01:00:00 GMT 1970
> Sun Apr 25 02:00:00 GMT 1971	Sun Oct 31 01:00:00 GMT 1971
> Sun Apr 30 02:00:00 GMT 1972	Sun Oct 29 01:00:00 GMT 1972
> Sun Apr 29 02:00:00 GMT 1973	Sun Oct 28 01:00:00 GMT 1973
> Sun Apr 28 02:00:00 GMT 1974	Sun Oct 27 01:00:00 GMT 1974
> 
> Should these not be taking place either seven or eight hours later
> according to GMT?  (I.e.  0200 PST, 0200 PDT) Am I misinterpreting the
> values in the timezone files?

i'll take another look.  i thought i worked this out for the us timezones,
and while confusing, i thought everything was working.

- erik

[9fans] dst shift is shifty

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> i'll take another look.  i thought i worked this out for the us timezones,
> and while confusing, i thought everything was working.

Heh. Either it's endemic or my morning coding skills are fscked:

lyndon at frodo% tzdump < Australia_West
                         WST	                         WDT
Sun Oct 27 02:00:00 GMT 1974	Sun Mar  2 02:00:00 GMT 1975
Sun Oct 30 02:00:00 GMT 1983	Sun Mar  4 02:00:00 GMT 1984
Sun Nov 17 02:00:00 GMT 1991	Sun Mar  1 02:00:00 GMT 1992
Sun Oct 28 02:00:00 GMT 2007	Sun Mar 30 02:00:00 GMT 2008
Sun Oct 26 02:00:00 GMT 2008	Sun Mar 29 02:00:00 GMT 2009

I vote for the latter at this point ...

[9fans] dst shift is shifty

[Steve Simon]

One I wrone a while ago when I have similar problems with UK timezones:

/n/sources/contrib/steve/rc/tzdump

-Steve