Wat. -_-##
Why?! I can see some localities deciding that having their time
zone not be an integer number of hours offset can be more
representative or useful for them, but why mess with the DST
offset, too? At this rate, they might as well just create a
server that calculates the sun's position in the sky on a
second-by-second basis and send out that time accordingly for
people to sync their computers to. -_-#
Bob
On Sun, 02 May 2021 10:26:24 +0100 Ralph Corderoy <ralph@inputplus.co.uk> sez:
Hi,
Bob wrote:
I found that (zone) provides you your "standard time" UTC offset (in
minutes), regardless of (dst)'s result.
nmh's code seems to assume DST means clocks wind forward sixty minutes,
which isn't always true, e.g.
$ TZ=Australia/Lord_Howe date -d '01 Aug'
2021-08-01 00:00:00 +1030 Sun
$ TZ=Australia/Lord_Howe date -d '01 Feb'
2021-02-01 00:00:00 +1100 Mon
One example is dlocaltime():
#ifdef HAVE_STRUCT_TM_TM_GMTOFF
tw.tw_zone = tm->tm_gmtoff / 60;
if (tm->tm_isdst) /* if DST is in effect */
tw.tw_zone -= 60; /* reset to normal offset */
#else
{
static bool deja_vu;
if (!deja_vu) {
deja_vu = true;
tzset();
}
}
tw.tw_zone = -(timezone / 60);
#endif
Of ‘timezone’ in the #else branch, tzset(3p) says
‘The external variable timezone shall be set to the difference, in
seconds, between Coordinated Universal Time (UTC) and local standard
time.’
--
Cheers, Ralph.