[tz] Java & Rearguard

[Guy Harris]

On Jun 2, 2019, at 10:10 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> On Sat, 1 Jun 2019 at 18:59, Paul Eggert <eggert at cs.ucla.edu> wrote:
>>> [The Java documentation] doesn't explicitly claim that the savings
>>> is positive
>> 
>> Yes, that was a real eye-opener to me. It means the Java developers could add
>> negative-DST support to Java without changing Java's documented API. From my
>> point of view it's a bug fix that's needed for POSIX compatibility anyway.

	...

> I've also indicated that there is no desire to support full POSIX:
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4263805

Presumably meaning "in theory, Java could be run, on a system that supports the full POSIX syntax for TZ, with TZ set to arbitrary POSIX-compliant values, including values in which clocks are turned *backwards* from standard time in the autumn and winter, but, in practice, that's insufficiently likely that there's any reason to make Java support it".

> What is unfortunate is the lack of desire to engage on the substantive point:
> * that both ways of describing the data are valid

"Valid" in what sense?

Yes, one could, when defining an API, either say:

	"standard time" is the time in effect in autumn and winter, even if that's not what some country's law defines as standard time, and clocks are turned forward from standard time for the spring and summer and turned back for autumn and winter;

	"standard time" is the time that the country's law defines as standard time, and clocks might be turned forward from standard time for the spring or summer, or might be turned backward from standard time for the autumn or winter.

For the tzdb, there is at least one API for which some implementations use the tzdb and for which it's not entirely clear which of those two interpretations is intended - namely the API for which the tzdb was originally created, and which remains an API for several OSes using the tzdb, such as most Linux distributions, the *BSDs, macOS, and Solaris, i.e. the POSIX API.  What the Single UNIX Specification page for <time.h>:

	https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

says is

	The value of tm_isdst shall be positive if Daylight Savings Time is in effect, 0 if Daylight Savings Time is not in effect, and negative if the information is not available.

On the other hand, what the same specification's page for Environment Variables:

	http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

says, of the TZ environment variable, is:

	The expanded format (for all TZ s whose value does not have a <colon> as the first character) is as follows:

	stdoffset[dst[offset][,start[/time],end[/time]]]


	Where:

	std and dst
		Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the alternative (dst -such as Daylight Savings Time) timezone. Only std is required; if dst is missing, then the alternative time does not apply in this locale.

suggesting that there's "standard time" and "alternative time", where "Daylight Savings Time" is an example of an "alternative time", but isn't necessarily the *definition* of "alternative time".

Before we conclude that ""standard time" is the time in effect in autumn and winter" is the POSIX definition, we should try to get this resolved by the Open Group, so we know which of the two definitions of "standard time" are valid in POSIX, and whether "tm_isdst" means "clocks have been turned forward" or "clocks are have been turned forward or backward from the legally-defined standard time".

If the decision is that the valid definition of "standard time" is "standard time as specified by law", and "tm_isdst" means "clocks have been turned forward or backward from the legally-defined standard time", then the tzdb needs to support that in some fashion, so that, for Europe/Dublin, "tm_isdst" is set for times during the autumn and winter" and that the "timezone" variable:

	https://pubs.opengroup.org/onlinepubs/9699919799/functions/daylight.html

be set to one hour in advance of UTC.  This would mean that it would need to distinguish between the way clocks are adjusted in most countries that do DST and the way they're adjusted in the Republic of Ireland - even though that might cause inconvenience for software using the "standard time is the time in effect in autumn and winter" view.

Paul, how should we go about requesting an interpretation from TOG here?  Presumably that would be done through the "Austin Group":

	https://www.opengroup.org/austin/