[tz] make error

Brian Inglis Brian.Inglis at Shaw.ca
Sat Nov 18 06:33:00 UTC 2023

On 2023-11-17 20:32, Philip Paeps via tz wrote:
> On 2023-11-18 03:20:41 (+0800), Paul Eggert via tz wrote:
>> On 2023-11-17 00:30, Robert Elz wrote:
>>> future version probably ought to be
>>> rather distant future, not next year sometime (or even the next few years
>>> after that).
>> Good point. From what we know now, 2029 might be a good year to do it, as RHEL 
>> 7 ELS ends June 2028. I installed the attached proposed patch. We can of 
>> course delay until after 2029 as more info becomes known.
> I think it's reasonable to expect everyone to have a C99 compiler by 2029.  The 
> standard will turn 30 years old that year.  Even the most tenacious long-term 
> support systems will have run out of support by then.  Moreover: the poor souls 
> stuck with maintaining those systems will have ample experience installing newer 
> compilers on them.
> Nobody will accuse the tz project of being hasty.  Especially since we're giving 
> 5+ years notice.
>>> It might be worth adding a "common issues" file
>> Yes, GNU Emacs does something like this, with its etc/PROBLEMS file (currently 
>> 4412 lines).
>> Currently TZDB puts this sort of thing in Makefile, which discusses the C89 
>> issue along with dozens of similar porting issues. Evidently Makefile isn't 
>> always being read; this is not surprising as it has hundreds of lines of 
>> comments.
>> Not sure that a separate PROBLEMS file (which would also have hundreds of 
>> lines) would always be read either. To some extent we'll always be stuck 
>> getting email saying "this doesn't work for me" by people who haven't had time 
>> to read the relevant documentation, regardless of where that documentation is.
>> For what it's worth, the Emacs etc/PROBLEMS file contains a long list of 
>> problems most of which nobody ever runs into nowadays, and hardly anybody 
>> reads the file.
> I agree that a separate file pointing out PROBLEMS won't encourage anyone to 
> read it.  Guy's suggestion, elsewhere in this thread, to add a pointer to the 
> Makefile in the README is a good idea.  At least README has a fighting chance of 
> being read ... the clue is in the name. :-)

Perhaps some document named something like idk FAQ? could point those with 
questions about policies, rules, zones, and data to Theory; processes to the 
RFC; building and code to the Makefile?

People with questions often look for a FAQ and posters and contributors have 
requested one be written to respond to the questions often asked on the list.
A small start in that direction could encourage patches to head off long threads.

Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

More information about the tz mailing list