Bug 103701

Summary:	timegm() manpage suggests a terrible workaround
Product:	Documentation	Reporter:	Stephen Hurd (shurd)
Component:	man-pages	Assignee:	documentation_man-pages (documentation_man-pages)
Status:	RESOLVED CODE_FIX
Severity:	low	CC:	mats, mtk.manpages
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:		Subsystem:
Regression:	No	Bisected commit-id:

Description Stephen Hurd 2015-08-29 10:36:07 UTC

In today's multi-threaded world, is changing an environment variable, calling tzset(), calling mktime(), changing the env variable back, and calling tzset() again really the best way to solve this problem?

Comment 1 Michael Kerrisk 2016-03-10 18:30:02 UTC

Stephen,

It's obviously not ideal. I added some words pointing out that it's not thread-safe. But, I have no further idea for changes. Do you?

Cheers,

Michael

Comment 2 Stephen Hurd 2016-03-10 20:00:33 UTC

I'm not sure why the manpage documents how to not use the function (obviously, documenting *why* not to use it makes sense.)

If there's honestly no good way to emulate timegm() in a threadsafe manner, should its use really be discouraged?

Comment 3 Mats Wichmann 2016-03-10 22:16:18 UTC

The Gnu glibc documentation has something like this in the portability notes.  Often the genesis of comments when there's a strange disclaimer in the manpage :)

I guess I'd suggest the page emphasize the UTC aspect and mention the threadsafe issue, and stop there - not try to document a workaround.

Comment 4 Michael Kerrisk 2016-03-10 23:48:14 UTC

Okay--you two convinced me. I killed the sample timegm() implementation and added mention of UTC. Thread-safety issues are covered already in ATTRIBUTES.