Date: Wed, 14 Dec 2022 08:08:36 +0700
From: "Robert Elz via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <11981.1670980...@jacaranda.noi.kre.to>
| Set the input to represent Jan 1, 2023, noon. (Jan 1 just so
| working out yday is simple....)
Which turns out to have been exactly the wrong thing to do for the
purposes of the example.
The point intended relates to computing tm_yday which depends upon
tm_mon and tm_mday (and also tm_year). That is, unless it is simply
0 as above...
One cannot compute tm_yday without knowing tm_mday tm_mon and tm_year,
and one cannot calculate those without first having normalized tm_sec
(which might affect tm_min when adjusted), tm_min (which might affect
tm_hour when adjusted) and tm_hour (which might affect tm_mday when
adjusted) - and of course, tm_mday, tm_mon, and tm_year have this weird
relationship where they all depend upon each other, though in practice,
nothing ever needs adjusting more than twice.
Still, the result is the same, the normalisation must happen before the
XBD 4.17 formula is applied.
kre
ps: for anyone who cares, here is the bc function I used when testing
this... (just so not everyone needs to copy all these magic numbers).
Remember the scale needs to be 0 (no fractions permitted).
define e() {
return ( s + mi*60 + hr*3600 + yd*86400 + (y-70)*31536000 +
((y-69)/4)*86400 - ((y-1)/100)*86400 + ((y+299)/400)*86400 )
}
then set s (tm_sec) mi (tm_min) hr (tm_hour) y (tm_year) and
calculate yd (tm_yday) from the supplied tm_mon and tm_mday (along
with tm_year).
