Hi Todd, Todd C. Miller wrote on Wed, Apr 22, 2020 at 09:21:28PM -0600: > On Thu, 23 Apr 2020 04:21:42 +0200, Ingo Schwarze wrote:
>> Calling timelocal(3) deprecated makes sense to me because it is >> nothing but a trivial wrapper around mktime(3), and the latter >> is standardized, while timelocal(3) is not. >> >> But i don't quite see why timegm(3) should be marked as deprecated: >> sure it was never standardized, but i don't see a better portable >> way to achieve the same. >> >> Consequently, i suggest dropping millert's deprecation notice >> from timegm(3) and instead adding the missing STANDARDS and >> HISTORY sections. > That's fine with me. Those interfaces appeared in SunOS 4.0 according > to tzcode (which is where we got them from). They did *not* originate > in NetBSD. I've verified that they were present in SunOS 4.1.3U1, > though that code appears to be derived from tzcode too. > > I would suggest that the HISTORY section be updated accordingly if > you feel the need to document their origin. > > If you look at the 4.4BSD ctime.c you'll see that Keith actually > removed timegm() after updating it from tzcode. > > D 5.16 89/03/16 20:34:41 bostic 22 21 > remove offtime, timegm, timeoff > > D 5.15 89/03/12 16:32:29 bostic 21 20 > latest Olson/Harris time package Thanks for doing that research and also for checking the rest of the patch. I tweaked the patch according to your findings and committed it. > The reason they were marked as deprecated is that tzcode has a > comment that "These functions may well disappear in future releases > of the time conversion package". However, that hasn't happened in > at least 30 years so it seems likely that they are here to stay... Sorry for calling you a muppet even though all you actually did was quoting the opinion muppets, a single time about two decades ago. ;-D > Note that we also provide timeoff() but don't document it. I have no strong opinion whether we should document it. Maybe not? I never felt a need to use it, and it isn't standardized. Are you suggesting that maybe we should? I wouldn't oppose that either. Yours, Ingo
