[tz] New leapseconds.awk doesn't work on macOS

enh enh at google.com
Sat Jan 11 06:26:15 UTC 2020


NetBSD already supported regular expressions in RS, and they
upstreamed that to one-true-awk last year
(https://github.com/onetrueawk/awk/commit/643a5a3dad633431c6ce8831944c23059a6be309
and https://github.com/onetrueawk/awk/commit/7cae39dfa53e17981990f649a2f6b4c1ba856112)
so hopefully all the OSes not using gawk can unify at some point. but,
yeah, right now most awks don't have this ability. (for Android builds
we're actually using one-true-awk on both Linux and macOS so
developers working on one can't break developers working on the
other.)

On Fri, Jan 10, 2020 at 9:31 PM Deborah Goldsmith via tz <tz at iana.org> wrote:
>
> Would it make sense to just use tr to strip carriage returns from the file before feeding it to the awk script?
>
> Thanks,
> Debbie
>
> > On Jan 10, 2020, at 7:32 PM, Deborah Goldsmith via tz <tz at iana.org> wrote:
> >
> > Hi,
> >
> > I just noticed that starting with 2019c, leapseconds.awk is producing a damaged leapseconds file on macOS, e.g.:
> >
> >> # All leap-seconds are Stationary (S) at the given UTC time.
> >> # The correction (+ or -) is made at the given time, so in the unlikely
> >> # event of a negative leap second, a line would look like this:
> >> # Leap  YEAR    MON     DAY     23:59:59        -       S
> >> # Typical lines look like this:
> >> # Leap  YEAR    MON     DAY     23:59:60        +       S
> >>
> >> # POSIX timestamps for the data in this file:
> >> #updated -2208988800 (1900-01-01 00:00:00 UTC)
> >> #expires -2208988800 (1900-01-01 00:00:00 UTC)
> >>
> >
> > It turns out that having a regex in RS is a gawk feature and is not supported in Darwin awk. Commenting out the definition of RS in leapseconds.awk fixed the problem.
> >
> > I don’t know how many customers of TZ will be using versions of awk that don’t support regexes in RS. I don’t know about FreeBSD, OpenBSD, etc.
> >
> > Thanks,
> > Debbie
> >
>


More information about the tz mailing list