[deathanatos]

> To do it simply yes, but not correctly.

No, it do it correctly doesn't require filesystem access either. I've read both articles in the past: neither refutes the point I made above. If I were incorrect, linking to an article that enumerates tens of things (some of them arguably incorrect) isn't useful.

If you're trying to imply that you need to take timezones into account, yes, you do. Yes, typically those definitions are stored on disk, but the context here is requiring filesystem access each and every time; most libraries (including glibc) will load the timezone definitions once, and keep them in memory. Thus, you can break a seconds-since-epoch out into year/mo/day/etc. with "simple" math, and it doesn't require a filesystem access. (Beyond the amortized one time load, but given the point and purposes of the article, I'm not considering that.)

[vsl]

Read the damn article. It explains how it's localtime (the function you need to format time in user's time zone) that makes the stat call - to check if the ocnfigured time zone changed.

[deathanatos]

> Read the damn article.

> Please don't insinuate that someone hasn't read an article

I read the article. Yes, localtime requires the call; that wasn't my point. My point was that for plenty of common, server-side code, either this isn't required, or is inconsequential.

The former case that I was consider is the formatting of timestamps into TZs in the context of a request being server by a server. Most server-side TZ conversions I've ever needed can't call localtime, b/c localtime is wired to not the user's timezone, but the TZ of the machine the server's code is running on, which is typically either nonsense, UTC, or whatever the devs like. Server side code needs (of course, YMMV) to use the user's TZ, whatever that may be, so I'm making calls to a library built for that, e.g., pytz, which doesn't need to stat() that the machines TZ as there is no point to doing so.

The other instances the author lists that do require localtime are instances where localtime's stat call is the least of your worries, as you're about to perform other operations that are much more expensive.

[cbsmith]

Timezones don't exclusively belong to users... Most syslogs (up until systemd) are configured to write out logs in machine localized time. Same goes for web servers. Really, there are a ton of cases where servers need to consider their timezone. I don't much like it, but it nevertheless is true.

[JdeBP]

> Most syslogs ... servers need

You have been using poor logging softwares. For the past decade and a half (or more) some of us have been using logging softwares that write out logs without converting timestamps to a local format or a local time, relying rather upon log post-processing tools to convert them to different (sometimes multiple) timezones of our choosing and at whim when we want to read our logs. Our servers haven't needed to consider timezones for all of those years, and our log-writing softwares don't call a localtime() function of any stripe. Please do not tar us with your brush.

* http://unix.stackexchange.com/a/326166/5132

* http://jdebp.eu./Softwares/nosh/guide/log-post-processing.ht...

* http://jdebp.eu./Softwares/nosh/guide/timestamps.html

* https://sawmill.net/formats/qmail_tai64_n.html

* https://www.elastic.co/guide/en/logstash/2.4/plugins-filters...

* http://docs.projectcalico.org/v1.6/usage/troubleshooting/log...

[cbsmith]

I haven't been using them I hate the whole approach and defer any rendering of timestamps in logs. I'm just pointing out that it is very commonplace. Set up any distro's server distribution with the default settings and then track how often the localtime file gets touched...

[lfowles]

Sounds like a misunderstanding of "simple" :)

[deathanatos]

Hence the scare quotes around simple. The math is in no way straightforward, but it's nonetheless math, esp. once you have the TZ information (if required) in front of you. The point was that there are plenty of operations within a typical server-side codebase that either involve little-to-no syscalls (tagging a record with the current UTC time, or converting a UTC timestamp to an ISO formatted date and time for serialization on the wire, e.g., JSON) or are forced to hit really expensive syscalls, rendering a quite-likely-cached-in-RAM stat() moot (logging, SQL queries).