From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, LOTS_OF_MONEY,T_TVD_MIME_EPI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 30301 invoked from network); 22 Oct 2023 11:15:08 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 22 Oct 2023 11:15:08 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 2f9df1ae for ; Sun, 22 Oct 2023 11:15:04 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id a416cd1f for ; Sun, 22 Oct 2023 11:15:03 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4DE0C61349; Sun, 22 Oct 2023 11:15:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AB8AC433C7; Sun, 22 Oct 2023 11:15:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697973303; bh=M8qieS/PknkWlqBppSknOZEfNqWce/Nqs6s354LzbAA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rWocyOQnJXsss09UJw9YlSrlHEkEGyP4oq+i+8UuomBqJxWv+kquQzZvyaDccWdvf nMO1P3Ex3BJMQiU7954vujB6I0oj/4/jlKKkdg6D91ZOMOEJw77JIJtjUjIFx2AaEI wcZHd5SmAeHt09lPbleHiMx/MoGQZvUTGFO7PAxD1iVSpl2C9WdzDObNMATMPwaZfe JiV4HfC4ojCQXHxy4qJ6XKYRp+fs+dr3Cx1nlnqiO4Yaur2P61H0qDi6VCJdyF7VVM U4/r619VGxkUuDMbEdlMtMG1fwQy/Y7Bv7S88dVXFkbdteSY6jOT822HcRZ/8rXKOu viFxto2qkmS2A== Date: Sun, 22 Oct 2023 13:14:59 +0200 From: Alejandro Colomar To: Paul Eggert Cc: Time Zone Database , mandoc Subject: Re: [man]: Bullet lists Message-ID: References: X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vhYN8AZuEDnAtmjn" Content-Disposition: inline In-Reply-To: --vhYN8AZuEDnAtmjn Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Oct 2023 13:14:59 +0200 From: Alejandro Colomar To: Paul Eggert Cc: Time Zone Database , mandoc Subject: Re: [man]: Bullet lists Oops, I should have CCd tech@, not discuss@. On Sun, Oct 22, 2023 at 12:58:17PM +0200, Alejandro Colomar wrote: > Hi Paul, >=20 > On Sat, Oct 21, 2023 at 05:36:03PM -0700, Paul Eggert wrote: > > On 2023-10-18 04:16, Alejandro Colomar wrote: > >=20 > > > I guess using '\[bu]' (or '\(bu') might not be appropriate for the tz > > > project, as it may be less portable to old systems > >=20 > > We should be ok with \(bu even with older nroff; I just checked with So= laris > > 10 nroff and it generated an ASCII 'o', same as GNU/Linux. > >=20 > >=20 > > > The change would be to use '.IP * 3' instead of '.IP * 2'. 3 is for = the > > > width of '*' +2. > >=20 > > 3 is equivalent to 3n, which is too much for PDF output. I installed the > > attached, which uses \w'\(bu 'u instead of 3. This is equivalent for t= o 3 > > for nroff, and has a better look for troff. >=20 > Hmm, interesting trick. To me, 3 doesn't look so excessive; it's at the > verge of being it, but still acceptable, but can understand your > preference. >=20 > The only downside I see to your approach (appart from making the source > more complex, but I'm willing to pay that for better output), is that > mandoc(1) doesn't seem to understand that, and falls back to the default > indentation, which is even more excessive. >=20 > Maybe we can report the problem to the maintainers of mandoc(1), > although I'm not sure how much they'll enjoy such low level roff(7) > stuff. >=20 > >=20 > > This patch also cleans up some of the other indenting irregularities in= TZDB > > man pages; for example, plain ".TP" is good enough, and we don't need "= =2ETP > > 10". Hope it works for you. >=20 > Thanks! LGTM. >=20 > > From 4a577028c65c70f6a85726ee34d307ee4a51b24d Mon Sep 17 00:00:00 2001 > > From: Paul Eggert > > Date: Sat, 21 Oct 2023 16:10:29 -0700 > > Subject: [PROPOSED] Be more systematic about man page indenting > >=20 > > This responds to a suggestion by Alejandro Colomar in: > > https://mm.icann.org/pipermail/tz/2023-October/033116.html > > --- > > newtzset.3 | 6 ++-- > > time2posix.3 | 2 +- > > tzfile.5 | 86 +++++++++++++++++++++++++++++----------------------- > > zdump.8 | 5 ++- > > zic.8 | 48 ++++++++++++++--------------- > > 5 files changed, 78 insertions(+), 69 deletions(-) > >=20 > > diff --git a/newtzset.3 b/newtzset.3 > > index 80617cd7..45ddbd24 100644 > > --- a/newtzset.3 > > +++ b/newtzset.3 > > @@ -115,7 +115,7 @@ it must have the following syntax (spaces inserted = for clarity): > > .PP > > Where: > > .RS > > -.TP 15 > > +.TP > > .IR std " and " dst > > Three or more bytes that are the designation for the standard > > .RI ( std ) > > @@ -205,7 +205,7 @@ The format of > > .I date > > is one of the following: > > .RS > > -.TP 10 > > +.TP > > .BI J n > > The Julian day > > .I n > > @@ -238,7 +238,7 @@ first week in which the > > .IR d' th > > day occurs. Day zero is Sunday. > > .RE > > -.IP "" 15 > > +.IP > > The > > .I time > > has the same format as > > diff --git a/time2posix.3 b/time2posix.3 > > index f48402b9..6644060a 100644 > > --- a/time2posix.3 > > +++ b/time2posix.3 > > @@ -100,7 +100,7 @@ and back from, > > the POSIX representation over the leap second inserted at the end of J= une, > > 1993. > > .nf > > -.ta \w'93/06/30 'u +\w'23:59:59 'u +\w'A+0 'u +\w'X=3Dtime2posix(T) 'u > > +.ta \w'93/06/30\0'u +\w'23:59:59\0'u +\w'A+0\0'u +\w'X=3Dtime2posix(T)= \0'u > > DATE TIME T X=3Dtime2posix(T) posix2time(X) > > 93/06/30 23:59:59 A+0 B+0 A+0 > > 93/06/30 23:59:60 A+1 B+1 A+1 or A+2 > > diff --git a/tzfile.5 b/tzfile.5 > > index 59d9f6ba..55280282 100644 > > --- a/tzfile.5 > > +++ b/tzfile.5 > > @@ -26,23 +26,24 @@ a signed binary integer is represented using two's = complement, > > and a boolean is represented by a one-byte binary integer that is > > either 0 (false) or 1 (true). > > The format begins with a 44-byte header containing the following field= s: > > -.IP * 2 > > +.RS "\w' 'u" > > +.IP \(bu "\w'\(bu 'u" > > The magic four-byte ASCII sequence > > .q "TZif" > > identifies the file as a timezone information file. > > -.IP * > > +.IP \(bu > > A byte identifying the version of the file's format > > (as of 2021, either an ASCII NUL, > > .q "2", > > .q "3", > > or > > .q "4" ). > > -.IP * > > +.IP \(bu > > Fifteen bytes containing zeros reserved for future use. > > -.IP * > > +.IP \(bu > > Six four-byte integer values, in the following order: > > -.RS > > -.TP > > +.RS "\w' \(bu 'u" > > +.TP "\w' 'u" > > .B tzh_ttisutcnt > > The number of UT/local indicators stored in the file. > > (UT is Universal Time.) > > @@ -68,14 +69,15 @@ stored in the file. > > .PP > > The above header is followed by the following fields, whose lengths > > depend on the contents of the header: > > -.IP * 2 > > +.RS "\w' 'u" > > +.IP \(bu "\w'\(bu 'u" > > .B tzh_timecnt > > four-byte signed integer values sorted in ascending order. > > These values are written in network byte order. > > Each is used as a transition time (as returned by > > .BR time (2)) > > at which the rules for computing local time change. > > -.IP * > > +.IP \(bu > > .B tzh_timecnt > > one-byte unsigned integer values; > > each one but the last tells which of the different types of local time= types > > @@ -85,20 +87,20 @@ and continuing up to but not including the next tra= nsition time. > > (The last time type is present only for consistency checking with the > > POSIX-style TZ string described below.) > > These values serve as indices into the next field. > > -.IP * > > +.IP \(bu > > .B tzh_typecnt > > .B ttinfo > > entries, each defined as follows: > > -.in +.5i > > +.in +2 >=20 > Hmm, I think I'll take this. The Linux man-pages currently use .in +4n > for examples, but maybe I can simplify to just +4 without the 'n'. I'll > check if the PDF isn't excessive. >=20 > Cheers, > Alex >=20 > > .sp > > .nf > > -.ta .5i +\w'unsigned char\0\0'u > > +.ta \w'\0\0\0\0'u +\w'unsigned char\0'u > > struct ttinfo { > > int32_t tt_utoff; > > unsigned char tt_isdst; > > unsigned char tt_desigidx; > > }; > > -.in -.5i > > +.in > > .fi > > .sp > > Each structure is written as a four-byte signed integer value for > > @@ -132,7 +134,8 @@ Also, in realistic applications > > is in the range [\-89999, 93599] (i.e., more than \-25 hours and less > > than 26 hours); this allows easy support by implementations that > > already support the POSIX-required range [\-24:59:59, 25:59:59]. > > -.IP * > > +.RS "\w' 'u" > > +.IP \(bu "\w'\(bu 'u" > > .B tzh_charcnt > > bytes that represent time zone designations, > > which are null-terminated byte strings, each indexed by the > > @@ -140,7 +143,7 @@ which are null-terminated byte strings, each indexe= d by the > > values mentioned above. > > The byte strings can overlap if one is a suffix of the other. > > The encoding of these strings is not specified. > > -.IP * > > +.IP \(bu > > .B tzh_leapcnt > > pairs of four-byte values, written in network byte order; > > the first value of each pair gives the nonnegative time > > @@ -167,18 +170,19 @@ otherwise, for timestamps before the first occurr= ence time, > > the leap-second correction is zero if the first pair's correction is 1= or \-1, > > and is unspecified otherwise (which can happen only in files > > truncated at the start). > > -.IP * > > +.IP \(bu > > .B tzh_ttisstdcnt > > standard/wall indicators, each stored as a one-byte boolean; > > they tell whether the transition times associated with local time types > > were specified as standard time or local (wall clock) time. > > -.IP * > > +.IP \(bu > > .B tzh_ttisutcnt > > UT/local indicators, each stored as a one-byte boolean; > > they tell whether the transition times associated with local time types > > were specified as UT or local time. > > If a UT/local indicator is set, the corresponding standard/wall indica= tor > > must also be set. > > +.RE > > .PP > > The standard/wall and UT/local indicators were designed for > > transforming a TZif file's transition times into transitions appropria= te > > @@ -312,15 +316,17 @@ This section documents common problems in reading= or writing TZif files. > > Most of these are problems in generating TZif files for use by > > older readers. > > The goals of this section are: > > -.IP * 2 > > +.RS "\w' 'u" > > +.IP \(bu "\w'\(bu 'u" > > to help TZif writers output files that avoid common > > pitfalls in older or buggy TZif readers, > > -.IP * > > +.IP \(bu > > to help TZif readers avoid common pitfalls when reading > > files generated by future TZif writers, and > > -.IP * > > +.IP \(bu > > to help any future specification authors see what sort of > > problems arise when the TZif format is changed. > > +.RE > > .PP > > When new versions of the TZif format have been defined, a > > design goal has been that a reader can successfully use a TZif > > @@ -335,21 +341,22 @@ workarounds, as well as to document other common = bugs in > > readers. > > .PP > > Interoperability problems with TZif include the following: > > -.IP * 2 > > +.RS "\w' 'u" > > +.IP \(bu "\w'\(bu 'u" > > Some readers examine only version 1 data. > > As a partial workaround, a writer can output as much version 1 > > data as possible. > > However, a reader should ignore version 1 data, and should use > > version 2+ data even if the reader's native timestamps have only > > 32 bits. > > -.IP * > > +.IP \(bu > > Some readers designed for version 2 might mishandle > > timestamps after a version 3 or higher file's last transition, because > > they cannot parse extensions to POSIX in the TZ-like string. > > As a partial workaround, a writer can output more transitions > > than necessary, so that only far-future timestamps are > > mishandled by version 2 readers. > > -.IP * > > +.IP \(bu > > Some readers designed for version 2 do not support > > permanent daylight saving time with transitions after 24:00 > > \(en e.g., a TZ string > > @@ -367,22 +374,22 @@ for the next time zone east \(en e.g., > > .q "AST4" > > for permanent > > Atlantic Standard Time (\-04). > > -.IP * > > +.IP \(bu > > Some readers designed for version 2 or 3, and that require strict > > conformance to RFC 8536, reject version 4 files whose leap second > > tables are truncated at the start or that end in expiration times. > > -.IP * > > +.IP \(bu > > Some readers ignore the footer, and instead predict future > > timestamps from the time type of the last transition. > > As a partial workaround, a writer can output more transitions > > than necessary. > > -.IP * > > +.IP \(bu > > Some readers do not use time type 0 for timestamps before > > the first transition, in that they infer a time type using a > > heuristic that does not always select time type 0. > > As a partial workaround, a writer can output a dummy (no-op) > > first transition at an early time. > > -.IP * > > +.IP \(bu > > Some readers mishandle timestamps before the first > > transition that has a timestamp not less than \-2**31. > > Readers that support only 32-bit timestamps are likely to be > > @@ -391,11 +398,11 @@ more prone to this problem, for example, when the= y process > > bits. > > As a partial workaround, a writer can output a dummy > > transition at timestamp \-2**31. > > -.IP * > > +.IP \(bu > > Some readers mishandle a transition if its timestamp has > > the minimum possible signed 64-bit value. > > Timestamps less than \-2**59 are not recommended. > > -.IP * > > +.IP \(bu > > Some readers mishandle POSIX-style TZ strings that > > contain > > .q "<" > > @@ -407,11 +414,11 @@ or > > .q ">" > > for time zone abbreviations containing only alphabetic > > characters. > > -.IP * > > +.IP \(bu > > Many readers mishandle time zone abbreviations that contain > > non-ASCII characters. > > These characters are not recommended. > > -.IP * > > +.IP \(bu > > Some readers may mishandle time zone abbreviations that > > contain fewer than 3 or more than 6 characters, or that > > contain ASCII characters other than alphanumerics, > > @@ -419,7 +426,7 @@ contain ASCII characters other than alphanumerics, > > and > > .q "+". > > These abbreviations are not recommended. > > -.IP * > > +.IP \(bu > > Some readers mishandle TZif files that specify > > daylight-saving time UT offsets that are less than the UT > > offsets for the corresponding standard time. > > @@ -435,7 +442,7 @@ thus swapping standard and daylight saving time. > > Although this workaround misidentifies which part of the year > > uses daylight saving time, it records UT offsets and time zone > > abbreviations correctly. > > -.IP * > > +.IP \(bu > > Some readers generate ambiguous timestamps for positive leap seconds > > that occur when the UTC offset is not a multiple of 60 seconds. > > For example, in a timezone with UTC offset +01:23:45 and with > > @@ -446,38 +453,41 @@ instead of mapping the latter to 01:23:46, and th= ey will map 78796815 to > > This has not yet been a practical problem, since no civil authority > > has observed such UTC offsets since leap seconds were > > introduced in 1972. > > +.RE > > .PP > > Some interoperability problems are reader bugs that > > are listed here mostly as warnings to developers of readers. > > -.IP * 2 > > +.RS "\w' 'u" > > +.IP \(bu "\w'\(bu 'u" > > Some readers do not support negative timestamps. > > Developers of distributed applications should keep this > > in mind if they need to deal with pre-1970 data. > > -.IP * > > +.IP \(bu > > Some readers mishandle timestamps before the first > > transition that has a nonnegative timestamp. > > Readers that do not support negative timestamps are likely to > > be more prone to this problem. > > -.IP * > > +.IP \(bu > > Some readers mishandle time zone abbreviations like > > .q "\*-08" > > that contain > > .q "+", > > .q "\*-", > > or digits. > > -.IP * > > +.IP \(bu > > Some readers mishandle UT offsets that are out of the > > traditional range of \-12 through +12 hours, and so do not > > support locations like Kiritimati that are outside this > > range. > > -.IP * > > +.IP \(bu > > Some readers mishandle UT offsets in the range [\-3599, \-1] > > seconds from UT, because they integer-divide the offset by > > 3600 to get 0 and then display the hour part as > > .q "+00". > > -.IP * > > +.IP \(bu > > Some readers mishandle UT offsets that are not a multiple > > of one hour, or of 15 minutes, or of 1 minute. > > +.RE > > .SH SEE ALSO > > .BR time (2), > > .BR localtime (3), > > diff --git a/zdump.8 b/zdump.8 > > index f77c0c79..c3f0bba6 100644 > > --- a/zdump.8 > > +++ b/zdump.8 > > @@ -152,10 +152,9 @@ tabbed columns line up.) > > .nf > > .sp > > .if \n(.g .ft CR > > -.if t .in +.5i > > -.if n .in +2 > > +.in +2 > > .nr w \w'1896-01-13 'u+\n(.i > > -.ta \w'1896-01-13 'u +\w'12:01:26 'u +\w'-103126 'u +\w'HWT 'u > > +.ta \w'1896-01-13\0\0'u +\w'12:01:26\0\0'u +\w'-103126\0\0'u +\w'HWT\0= \0'u > > TZ=3D"Pacific/Honolulu" > > - - -103126 LMT > > 1896-01-13 12:01:26 -1030 HST > > diff --git a/zic.8 b/zic.8 > > index 6bcef7ae..a958ddd1 100644 > > --- a/zic.8 > > +++ b/zic.8 > > @@ -95,7 +95,7 @@ as local time. > > .B zic > > will act as if the input contained a link line of the form > > .sp > > -.ti +.5i > > +.ti +2 > > .ta \w'Link\0\0'u +\w'\fItimezone\fP\0\0'u > > Link \fItimezone\fP localtime > > .sp > > @@ -118,7 +118,7 @@ TZ strings like "EET\*-2EEST" that lack transition = rules. > > .B zic > > will act as if the input contained a link line of the form > > .sp > > -.ti +.5i > > +.ti +2 > > Link \fItimezone\fP posixrules > > .sp > > If > > @@ -330,19 +330,19 @@ abbreviation must be unambiguous in context. > > .PP > > A rule line has the form > > .nf > > -.ti +.5i > > +.ti +2 > > .ta \w'Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'\*-= \0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00w\0\0'u +\w'1:00d\0\0'u > > .sp > > Rule NAME FROM TO \*- IN ON AT SAVE LETTER/S > > .sp > > For example: > > -.ti +.5i > > +.ti +2 > > .sp > > Rule US 1967 1973 \*- Apr lastSun 2:00w 1:00d D > > .sp > > .fi > > The fields that make up a rule line are: > > -.TP "\w'LETTER/S'u" > > +.TP > > .B NAME > > Gives the name of the rule set that contains this line. > > The name must start with a character that is neither > > @@ -404,7 +404,7 @@ Month names may be abbreviated. > > Gives the day on which the rule takes effect. > > Recognized forms include: > > .nf > > -.in +.5i > > +.in +2 > > .sp > > .ta \w'Sun<=3D25\0\0'u > > 5 the fifth of the month > > @@ -413,7 +413,7 @@ lastMon the last Monday in the month > > Sun>=3D8 first Sunday on or after the eighth > > Sun<=3D25 last Sunday on or before the 25th > > .fi > > -.in -.5i > > +.in > > .sp > > A weekday name (e.g., > > .BR "Sunday" ) > > @@ -440,7 +440,7 @@ Gives the time of day at which the rule takes effec= t, > > relative to 00:00, the start of a calendar day. > > Recognized forms include: > > .nf > > -.in +.5i > > +.in +2 > > .sp > > .ta \w'00:19:32.13\0\0'u > > 2 time in hours > > @@ -454,7 +454,7 @@ Recognized forms include: > > \*-2:30 2.5 hours before 00:00 > > \*- equivalent to 0 > > .fi > > -.in -.5i > > +.in > > .sp > > Although > > .B zic > > @@ -532,18 +532,18 @@ the variable part is null. > > A zone line has the form > > .sp > > .nf > > -.ti +.5i > > +.ti +2 > > .ta \w'Zone\0\0'u +\w'Asia/Amman\0\0'u +\w'STDOFF\0\0'u +\w'Jordan\0\0= 'u +\w'FORMAT\0\0'u > > Zone NAME STDOFF RULES FORMAT [UNTIL] > > .sp > > For example: > > .sp > > -.ti +.5i > > +.ti +2 > > Zone Asia/Amman 2:00 Jordan EE%sT 2017 Oct 27 01:00 > > .sp > > .fi > > The fields that make up a zone line are: > > -.TP "\w'STDOFF'u" > > +.TP > > .B NAME > > The name of the timezone. > > This is the name used in creating the time conversion information file= for the > > @@ -663,15 +663,15 @@ For example: > > .br > > .ne 7 > > .nf > > -.in +2m > > +.in +2 > > .ta \w'# Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'2006\0\0'u +\w'\= *-\0\0'u +\w'Oct\0\0'u +\w'lastSun\0\0'u +\w'2:00\0\0'u +\w'SAVE\0\0'u > > .sp > > # Rule NAME FROM TO \*- IN ON AT SAVE LETTER/S > > Rule US 1967 2006 - Oct lastSun 2:00 0 S > > Rule US 1967 1973 - Apr lastSun 2:00 1:00 D > > -.ta \w'Zone\0\0America/Menominee\0\0'u +\w'STDOFF\0\0'u +\w'RULES\0\0'= u +\w'FORMAT\0\0'u > > -# Zone\0\0NAME STDOFF RULES FORMAT [UNTIL] > > -Zone\0\0America/Menominee \*-5:00 \*- EST 1973 Apr 29 2:00 > > +.ta \w'# Zone\0\0'u +\w'America/Menominee\0\0'u +\w'STDOFF\0\0'u +\w'R= ULES\0\0'u +\w'FORMAT\0\0'u > > +# Zone NAME STDOFF RULES FORMAT [UNTIL] > > +Zone America/Menominee \*-5:00 \*- EST 1973 Apr 29 2:00 > > \*-6:00 US C%sT > > .sp > > .in > > @@ -687,13 +687,13 @@ interprets this more sensibly as a single transit= ion from 02:00 CST (\*-05) to > > A link line has the form > > .sp > > .nf > > -.ti +.5i > > +.ti +2 > > .ta \w'Link\0\0'u +\w'Europe/Istanbul\0\0'u > > Link TARGET LINK-NAME > > .sp > > For example: > > .sp > > -.ti +.5i > > +.ti +2 > > Link Europe/Istanbul Asia/Istanbul > > .sp > > .fi > > @@ -717,7 +717,7 @@ For example: > > .sp > > .ne 3 > > .nf > > -.in +2m > > +.in +2 > > .ta \w'Zone\0\0'u +\w'Greenwich\0\0'u > > Link Greenwich G_M_T > > Link Etc/GMT Greenwich > > @@ -737,13 +737,13 @@ The file that describes leap seconds can have lea= p lines and an > > expiration line. > > Leap lines have the following form: > > .nf > > -.ti +.5i > > +.ti +2 > > .ta \w'Leap\0\0'u +\w'YEAR\0\0'u +\w'MONTH\0\0'u +\w'DAY\0\0'u +\w'HH:= MM:SS\0\0'u +\w'CORR\0\0'u > > .sp > > Leap YEAR MONTH DAY HH:MM:SS CORR R/S > > .sp > > For example: > > -.ti +.5i > > +.ti +2 > > .sp > > Leap 2016 Dec 31 23:59:60 + S > > .sp > > @@ -791,13 +791,13 @@ option is used. > > .PP > > The expiration line, if present, has the form: > > .nf > > -.ti +.5i > > +.ti +2 > > .ta \w'Expires\0\0'u +\w'YEAR\0\0'u +\w'MONTH\0\0'u +\w'DAY\0\0'u > > .sp > > Expires YEAR MONTH DAY HH:MM:SS > > .sp > > For example: > > -.ti +.5i > > +.ti +2 > > .sp > > Expires 2020 Dec 28 00:00:00 > > .sp > > @@ -816,7 +816,7 @@ Here is an extended example of > > .B zic > > input, intended to illustrate many of its features. > > .nf > > -.in +2m > > +.in +2 > > .ta \w'# Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'\= *-\0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00\0\0'u +\w'SAVE\0\0'u > > .sp > > # Rule NAME FROM TO \*- IN ON AT SAVE LETTER/S > > --=20 > > 2.39.2 > >=20 >=20 >=20 > --=20 > --=20 --vhYN8AZuEDnAtmjn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmU1BDMACgkQnowa+77/ 2zIKPA//THTE2ZgQ7UEXLxu8emLugwAFemZ0fgGPRTZlBG3klhxqKAOHKS/U1l9/ nWxo1C9rJGkI8wEiupRYq5Ufnce8vcPdpCrKsHKntDgR7pPElvEBFynWB0R9ha0V RpheWHGiBs+nQoqma/7B6RdW4MnqyhyIN5KPHDzcFLURh66wQYTgjzTH6VkD7F4P NbuB5P49O2opZ/etcRJg9QDeLro6oDHcBh3jNzI+tdyV6U4cEevgWf0c7qLwktw5 f9nQdC3TTcch0aP9QgtTImXo0whdD4KVPWMBPM1+NYtyMJeNHbRqi+3s36+Y3inj sN9NMXou3P9/GZ1HgUxwlB3r4fA2QzOPWyJZANe4xhnF7UF9VEz41FK/tvERcK3K s0WEEGCqjFvTfnLnoJebRYmBQve5buDenDpbRP/07j3acInd7jFRDYqMiaRuTlpP qEYTvXdF/zezX+pGx3sfPLlP8UJ0RJZ8A18kp0+Nc6JzwaMRC9WNAiMDFVg51F0i S0UVNPZxDIlBmQABIRzuwYYsr3Yro4sWFYR7ZHe860vN996lschGl3TQXFsrNAHG FbpluVajEnrP91XuHrRHUl14S0QFqBXW6pSJG7iWtkP80SRaxHHrVmwxisnZHjFr OPpbhlHL1S/lGyDk+4R4LTnoH6QoaRkN8CW9fTCR0FH4Kkdkahs= =SyKc -----END PGP SIGNATURE----- --vhYN8AZuEDnAtmjn-- -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv