Re: timegm()
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
Re: timegm()
Todd C. Miller wrote: > On Wed, 22 Apr 2020 21:21:28 -0600, "Todd C. Miller" wrote: > > > 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. > > Bit Savers has scans of the SunOS 4.0 print manuals which includes > a hard-copy of the man pages. Here you can see that timegm() and > timelocal() were present in SunOS in 1987: > > archive.org/details/bitsavers_sunsunos4.erenceManual198805_78292584/page/n823/mode/2up > > However, they are not present in SunOS 3.5. You can see the list > of library functions from intro(3) which includes gmtime(3) and > localtime(3) but not their inverses: > > https://archive.org/details/bitsavers_sunsunos3.eManualInsertionPagesforRelease3.5198711_7929431/page/n145/mode/2up > > So I think it is safe to say that those interfaces originated in > SunOS 4.0 and not an earlier version. I believe it.
Re: timegm()
On Wed, 22 Apr 2020 21:21:28 -0600, "Todd C. Miller" wrote: > 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. Bit Savers has scans of the SunOS 4.0 print manuals which includes a hard-copy of the man pages. Here you can see that timegm() and timelocal() were present in SunOS in 1987: archive.org/details/bitsavers_sunsunos4.erenceManual198805_78292584/page/n823/mode/2up However, they are not present in SunOS 3.5. You can see the list of library functions from intro(3) which includes gmtime(3) and localtime(3) but not their inverses: https://archive.org/details/bitsavers_sunsunos3.eManualInsertionPagesforRelease3.5198711_7929431/page/n145/mode/2up So I think it is safe to say that those interfaces originated in SunOS 4.0 and not an earlier version. - todd
Re: timegm()
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 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... Note that we also provide timeoff() but don't document it. - todd
Re: timegm()
Hi, Theo de Raadt wrote on Wed, Apr 22, 2020 at 12:11:56AM -0600: > William Ahern wrote: >> On Tue, Apr 21, 2020 at 02:01:10PM +0200, Otto Moerbeek wrote: >>> On Tue, Apr 21, 2020 at 10:51:54AM +, Roderick wrote: >>>> Acording to the man page: "timegm() is a deprecated interface that >>>> converts [...]" >>>> O.K., deprecated. And what is the alternative? >>> The paragraph above it (discussing timelocal()) suggests it's >>> mktime(). >> There is no alternative to timegm that is thread-safe. timegm is widely >> supported, including BSDs, glibc, musl; it shouldn't be deprecated, IMNSHO. >> Solaris even recently reintroduced timegm (with 11.4) after having removed >> it years ago. > It is marked deprecated. > That doesn't mean it is going away. > It's just a pseudo-legal term by a bunch of muppets. The particular muppet here appears to be known by the name of millert@ ;-) revision 1.23 date: 2000/08/22 14:21:23; author: millert; state: Exp; lines: +23 -3; Quickly describe timelocal() and timegm() and note that they are deprecated interfaces. 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. timegm(3) and timelocal(3) are neither in the final state of the 4.4BSD SCCS repo nor in 386BSD, but first appear here: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/time/localtime.c?rev=1.1=text/x-cvsweb-markup/ That is between NetBSD 1.0 (Oct 94) and 1.1 (Nov 95). The STANDARDS stuff is easy to verify from C89, C11, and POSIX, the v5 stuff from TUHS, difftime and mktime from the CSRG history, and the addition of the four *_r() functions from our own CVS history. While here, purge the non-standard section name NOTES; the normal name for such a section is CAVEATS. OK? Ingo Index: ctime.3 === RCS file: /cvs/src/lib/libc/time/ctime.3,v retrieving revision 1.44 diff -u -r1.44 ctime.3 --- ctime.3 14 Sep 2015 13:08:01 - 1.44 +++ ctime.3 23 Apr 2020 02:13:54 - @@ -201,7 +201,7 @@ .Fa tm_isdst . .Pp .Fn timegm -is a deprecated interface that converts the broken-down time, as returned by +converts the broken-down time, as returned by .Fn gmtime , into a calendar time value with the same encoding as that of the values returned by the @@ -295,12 +295,68 @@ .Xr tzset 3 , .Xr tzfile 5 , .Xr zic 8 +.Sh STANDARDS +The functions +.Fn asctime , +.Fn ctime , +.Fn difftime , +.Fn gmtime , +.Fn localtime , +and +.Fn mktime +conform to +.St -ansiC . +.Pp +The functions +.Fn asctime_r , +.Fn ctime_r , +.Fn gmtime_r , +and +.Fn localtime_r +conform to +.St -p1003.1-2008 . +.Pp +The functions +.Fn timegm +and +.Fn timelocal +are extensions to these standards. .Sh HISTORY A .Fn ctime function first appeared in .At v1 . -.Sh NOTES +.Pp +The functions +.Fn asctime , +.Fn gmtime , +and +.Fn localtime +first appeared in +.At v5 . +.Pp +The functions +.Fn difftime +and +.Fn mktime +first appeared in +.Bx 4.3 Reno . +.Pp +The functions +.Fn timegm +and +.Fn timelocal +have been available since +.Nx 1.1 +and +.Fn asctime_r , +.Fn ctime_r , +.Fn gmtime_r , +and +.Fn localtime_r +since +.Ox 2.5 . +.Sh CAVEATS The return values of the non re-entrant functions point to static data;
Re: timegm()
William Ahern wrote: > On Tue, Apr 21, 2020 at 02:01:10PM +0200, Otto Moerbeek wrote: > > On Tue, Apr 21, 2020 at 10:51:54AM +, Roderick wrote: > > > > > > > > Acording to the man page: "timegm() is a deprecated interface that > > > converts [...]" > > > > > > O.K., deprecated. And what is the alternative? > > > > > > Thanks for any hint > > > Rodrigo > > > > > > > The paragraph above it (discussing timelocal()) suggests it's > > mktime(). > > There is no alternative to timegm that is thread-safe. timegm is widely > supported, including BSDs, glibc, musl; it shouldn't be deprecated, IMNSHO. > Solaris even recently reintroduced timegm (with 11.4) after having removed > it years ago. It is marked deprecated. That doesn't mean it is going away. It's just a pseudo-legal term by a bunch of muppets.
Re: timegm()
On Tue, Apr 21, 2020 at 02:01:10PM +0200, Otto Moerbeek wrote: > On Tue, Apr 21, 2020 at 10:51:54AM +, Roderick wrote: > > > > > Acording to the man page: "timegm() is a deprecated interface that > > converts [...]" > > > > O.K., deprecated. And what is the alternative? > > > > Thanks for any hint > > Rodrigo > > > > The paragraph above it (discussing timelocal()) suggests it's > mktime(). There is no alternative to timegm that is thread-safe. timegm is widely supported, including BSDs, glibc, musl; it shouldn't be deprecated, IMNSHO. Solaris even recently reintroduced timegm (with 11.4) after having removed it years ago.
Re: timegm()
On Tue, 21 Apr 2020, Otto Moerbeek wrote: O.K., deprecated. And what is the alternative? The paragraph above it (discussing timelocal()) suggests it's mktime(). Thanks. I would preffer to reimplement timegm if it disappears than going trhough the locale: it should be one or two lines with trivial arithmetic calculations. Rodrigo
Re: timegm()
On Tue, Apr 21, 2020 at 10:51:54AM +, Roderick wrote: > > Acording to the man page: "timegm() is a deprecated interface that > converts [...]" > > O.K., deprecated. And what is the alternative? > > Thanks for any hint > Rodrigo > The paragraph above it (discussing timelocal()) suggests it's mktime(). -Otto
timegm()
Acording to the man page: "timegm() is a deprecated interface that converts [...]" O.K., deprecated. And what is the alternative? Thanks for any hint Rodrigo
