Jump to content

Talk:C date and time functions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is the current revision of this page, as edited by Cewbot (talk | contribs) at 16:48, 29 January 2024 (Maintain {{WPBS}} and vital articles: 1 WikiProject template. Create {{WPBS}}. Keep majority rating "Start" in {{WPBS}}. Remove 1 same rating as {{WPBS}} in {{WikiProject C/C++}}.). The present address (URL) is a permanent link to this version.

(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

This is not C documentation

[edit]

Wikipedia is not C documentation.

Why not? What else would you put here? --a_dergachev 07:58, 8 October 2007 (UTC)[reply]
He is correct, see WP:NOT#HOWTO. -- intgr [talk] 14:18, 8 October 2007 (UTC)[reply]
Yeah Guys.. Just something to think about.. An encyclopedic Article on time.h would be - well just useless. And i'm happy with the english wikipedia as it is, with thousands of articles to even minor details, headerfiles, comic characters and so on. Please just don't take the german wiki as model, its so full of relevancy that it became entirely irrelevant. Rules like the NO-HOWTO are nice, but only IF the article would be better in an encyclopedic form - not in this case.77.11.26.13 (talk) 20:43, 16 February 2010 (UTC)[reply]


Also, it's not strictly correct. On at least some systems (most?) there is time.h and sys/time.h, which are not identical. It would be nice if Wikipedia were truely autoritative, but one more partly-correct source is not helpful, IMO. — Preceding unsigned comment added by 184.71.25.218 (talk) 22:31, 21 August 2012 (UTC)[reply]

Move discussion in progress

[edit]

There is a move discussion in progress which affects this page. Please participate at Talk:C standard library - Requested move and not in this talk page section. Thank you. —RM bot 09:40, 8 November 2011 (UTC)[reply]

time_t

[edit]

Regarding the "time_t - time since epoch type". This is not true actually as shown in the specification http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf See on page 350 at 7.23.1.(4) Components of time: "The range and precision of times representable in clock_t and time_t are implementation-defined.". Thus, it should be "time_t - time since epoch type for most compilers such as gcc"! (see http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_21.html) — Preceding unsigned comment added by 195.244.120.156 (talk) 13:55, 23 November 2011 (UTC)[reply]

I don't understand what was wrong with the previous statement. time_t means "time since epoch" or "calendar time" in all contexts as per specification. The undefined thing is the format of the type, not what it represents. Thus since the previous definition doesn't specify anything about the format, it's still correct. 1exec1 (talk) 16:28, 23 November 2011 (UTC)[reply]
There is no requirement in C that time_t be implemented as time since an epoch. (Posix requires this, but not C.) I've updated several function descriptions accordingly. —Steve Summit (talk) 16:14, 17 November 2015 (UTC)[reply]

Proposed rename

[edit]

I propose to rename the article from C date and time operations to C date and time functions per WP:COMMONNAME. 1exec1 (talk) 16:29, 23 November 2011 (UTC)[reply]

Since I've received exactly zero input, I've moved the page. If anyone disagrees, please express your concerns here. Thanks. 1exec1 (talk) 16:20, 25 November 2011 (UTC)[reply]

whitespace and compilation

[edit]

Recently an anonymous editor changed the whitespace from simple spaces to tabs, claiming "UNIX-style indentation" had to be with tabs, not spaces. I reverted this because a) whitespace in C can be spaces, horizontal tabs, vertical tabs and newlines, b) UNIX-style does not restrict it to tabs only, c) those massive, wide tabs seem un-aesthetic to me (that's a personal thing but the industry seems to like 3 or 4 space indentation) and d) even under flame war discussions, the original indentation was perfectly serviceable. He also claimed that (void) has to be used when the return value of printf() is ignored. It certainly can be used that way but is by no means required. To my mind, this cast gets in the way of this example. A clean, minimal source is preferred so that the topic under discussion is highlighted, without distractions. Lastly, he also added a sample compilation and invocation. This only applies to UNIX and doesn't take into account compilation and invocation under Windows, Macs, cross compilers for embedded systems, etc. This isn't an article on compiling and invoking C programs. For users not used to Unix, they now have to figure what parts of that are the commands, what parts are the prompts and what part is the actual output. Much better to simply show the output and leave it at that. Thoughts?  Stepho  talk  00:18, 11 March 2012 (UTC)[reply]

I agree with all your points. I would add that indentation isn't only a personal thing - Wikipedia prefers consistent style. If we look around, we will see that most of the examples use the original indentation style. So I'd support reverting the changes to the indentation too. 1exec1 (talk) 23:49, 11 March 2012 (UTC)[reply]
As for indentation, it isn′t about consistency on Wikipedia, but is about conforming to the common style of the industry. 213.131.238.28 (talk) 09:38, 12 March 2012 (UTC)[reply]
That anonymous editor was me. First, I′m a C expert and as such am aware that C is a free-form language, allowing both spaces and tabs as whitespace (along with a few other characters); I never claimed tabs to be the sole delimiter — that′s why I wrote “UNIX-style indentation”, alluding to mere stylistic nature of the matter. It isn′t important whether to use spaces or tabs in such code snippets, the indentation part of my edit was purely aesthetical, made in accordance to my personal (and quite popular) views:
  • Tab is more flexible, because most text editors allow you to set the tab width, allowing for quick indentation adjustments without any changes to the actual code.
  • Tab is far more common as an indentation character and is used extensively throughout the industry — this is why your industry comment is false — industry uses tabs with tab width set to either 4 or 8 (never odd, like 3), you can easily see that for yourself by examining source code (quick examples: Solaris, IRIX, Linux, and FreeBSD kernels.) I am myself part of this industry, being a C programmer for Cadence Design Systems, Inc. You are, on the contrary, either an amateur or most likely not a C programmer at all, which is easily deduced from your comment on industrial usage of tabs — apparently you never even read any source code of operating systems, drivers, or system software, otherwise you wouldn′t make that erroneous statement. This is why my professional opinion holds a much higher value.
  • Tab is more practical, because it takes less bytes to represent a string of tabs compared to a string of spaces of the same visible width.
  • Tab is very handy for automated code editing by scripts (regular expressions become ten times simpler, compared to equivalents written for space-indented code) — the technique used extensively throughout the industry for large spanning source trunks and branches.
By using tabs for indentation of example code snippets on Wikipedia we promote a reasonable, practical, and just handy coding technique, which, in common sense, is a virtue to be chased. Moreover, I noted UNIX because it is the origin of the C programming language, its source code therefore can and should be taken as a reliable source of good C programming practices, including the style.
Second, I never claimed the void cast to be required — I wrote should, indicating its optional nature. Such void casts are deemed to be a good practice, because just by glancing at code you can easily tell which calls′ return values are ignored. It is a heavily used (by industry, yeah) convenience technique of the same order as prefixing struct/union member names with struct/union′s shortened name, for example:
struct iovec {
	void		*iov_base;
	size_t		iov_len;
};
But okay, your point here is reasonable, so let′s keep the cast out and leave it to industry. I agree with your compilation and invocation point too — I tend to forget that non-UNIX operating systems exist, my bad.
Resume: you twisted every single bit of my edit′s explanation message, reading “required” instead of “optional” and not undestanding the stylistic nature of tab usage. You aren′t even a professional C programmer. Why do you edit C-related articles when you aren′t knowledgeable enough?
Au revoir. 213.131.238.28 (talk) 09:38, 12 March 2012 (UTC)[reply]
Curious. I thought a computing degree and 24 years as a paid programmer using mostly C was enough to qualify as a C professional. Perhaps all those years of embedded programming of real time clock chips, serial chips, LCD driver chips, interrupt handlers, etc on embedded systems for trivial applications like EFTPOS, airport security scanners and high speed network backbone systems isn't enough. Obviously I need to work at it a bit longer to get away from my amateur status :)
Apologies if I misinterpreted 'requires' for 'should'.
I didn't want to get into a flame war over indentation - it's a no win scenario. Be aware that there is no such thing as UNIX style for indentation. Perhaps you meant BSD KNF style? Different places have different forms. Some shops favour one way and some shops favour others. I've seen practically every possible way, each used across all the common systems (Linux, BSD, UNIX, Solaris, Windows, VMS and many others). Mostly it is a matter of taste, with no clear advantage to any of them.
However, I have found that various editors do strange things to tabs. The problem comes when team members uses different editors (many programmers have very strong preferences for their favourite editor) or different settings. Assume the first programmer uses an editor that displays tabs as 4 spaces. Then the next programmer uses an editor that displays tabs as 3 spaces and also translates new tab key presses into 3 spaces (jEdit, vi, emacs and many others can do this). So far it all looks fine for the second programmer. Then it goes back to the first programmer but he sees a mix of 3 space indentation and tabs displayed as 4 spaces - horrible! Sad to say but I have seen many so called professional companies do this. Wikipedia promises to be even worse.
Anyway, no hard feelings!  Stepho  talk  13:09, 12 March 2012 (UTC)[reply]
No, it's indeed about consistency in Wikipedia. The industry standard isn't that relevant, since here most of the code examples here span at most 20 lines and what matters is readability in such very specific circumstances. We are not dealing with 100000+ LOC projects or 1000+ LOC files either, so the cited advantages of tabs largely doesn't apply. In addition to that, most of the readers are not C professionals and they don't necessarily expect to see kernel style here. Lastly, C standard library is available in C++ and Wikipedia doesn't apparently have articles such as C date and time functions in C++. Thus, the consistency of C and C++ examples is also beneficial.
So if you want to change the indentation style used here, the usual procedure involving such comparatively major changes is to go to Wikipedia_talk:WikiProject Computing or Talk:C programming language and propose the change. But I probably should warn you to be prepared for a long flamewar, since this is what most of similar discussions become. Until there's consensus for a new indentation style, it should stay as is. 1exec1 (talk) 16:42, 18 March 2012 (UTC)[reply]

Leap seconds?

[edit]

Does the value of time_t include leap seconds? — Preceding unsigned comment added by 82.139.81.0 (talk) 06:27, 4 June 2013 (UTC)[reply]

No. Applications frequently assume that days are exactly 86400 seconds long. Leap seconds are implemented by "stretching" one time_t second over two real seconds. -- intgr [talk] 08:02, 4 June 2013 (UTC)[reply]
time_t does not typically reflect leap seconds, although in principle it could.
(With that said, Posix requires that time_t not reflect leap seconds, which is one reason most implementations don't.)
[But with that said, I believe that computer systems could handle leap seconds much more cleanly if time_t did explicitly reflect leap seconds, but that's another story.] —Steve Summit (talk) 16:20, 17 November 2015 (UTC)[reply]

Completeness

[edit]

The information is also incomplete. It only discusses those functions that deal with second precision. I came here hoping to find useful information for micro- or nanosecond double values, not merely int equivalents. — Preceding unsigned comment added by 71.179.41.98 (talkcontribs)

New topics go at the bottom of the talk page. Each topic should have its own title. Each comment should be signed by placing 4 tilde characters at the end (ie ~~~~).
This page covers all the functions of the standard C library. The standard C library only goes down to seconds. Anything more precise is handled by extensions or alternatives to the standard C library and is therefore not meant to be covered in this article.  Stepho  talk  20:43, 22 April 2020 (UTC)[reply]

India Education Program course assignment

[edit]

This article was the subject of an educational assignment at College Of Engineering Pune supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 20:07, 1 February 2023 (UTC)[reply]