GTimeZone fails to accept full Julian day range when parsing the direct $TZ string format
The $TZ env variable can accept a direct timezone definition using a syntax:
std offset[dst[offset][,start[/time],end[/time]]]
The start field specifies when daylight saving time goes into effect and the end field specifies when the change is made back to standard time. These fields may have the following formats:
-
Jn
This specifies the Julian day with n between 1 and 365. Leap days are not counted. In this format, February 29 can't be represented; February 28 is day 59, and March 1 is always day 60. -
n
This specifies the zero-based Julian day with n between 0 and 365. February 29 is counted in leap years. -
Mm.w.d
This specifies day d (0 <= d <= 6) of week w (1 <= w <= 5) of month m (1 <= m <= 12). Week 1 is the first week in which day d occurs and week 5 is the last week in which day d occurs. Day 0 is a Sunday.
GTimeZone attempts to support this syntax, but it is incorrectly implementing the n
syntax, only allowing a range 1 -> 365
. There is a code comment saying this was an intentional choice, however, that comment is evidently based off reading old Linux man pages which were themselves incorrectly saying the range was 1 -> 365
. glibc implements this correctly with the range 0 -> 365
.
The result is that this string
VIR-00:30VID,0/00:00:00,365/23:59:59
is rejected by GTimeZone. This was identified when porting libvirt to use the GTimeZone APIs, since our test suite validates these timezone strings.