Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How setting the TZ environment variable avoids thousands of system calls

blog.packagecloud.io

Post reply on HN
Print view View original

131–140 of 148 posts

Re: How setting the TZ environment variable avoids thousands of system calls

#131

Post by lfowles »

deathanatos wrote: post #128
lfowles wrote: post #122

Earlier quoted context omitted.

>Breaking a seconds-since-epoch out into year/mo/day/etc. is "simple" math, and shouldn't require a filesystem access. To do it simply yes, but not correctly. See the "Falsehoods programmers believe about time" series. http://infiniteundo.com/post/25326999628/falsehoods-programm... http://infiniteundo.com/post/25509354022/more-falsehoods-pro...

> 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 definiti…

Sounds like a misunderstanding of "simple" :)

Re: How setting the TZ environment variable avoids thousands of system calls

#132

Post by int_19h »

Daviey wrote: post #32

Honestly, the primary reason I support this is to get developers out of the habbit of demanding a localized server timezone. As an infra' person, I want system time in UTC. If developers get in the habbit of setting TZ, then I can have this!

It feels like any code that needs to know the timezone of the server is inherently wrong. If timezone ever comes up in any context, it's either the timezone of the client from whom the request originates - in which case it should come as part of the request - or else the timezone somehow associated with the business process (e.g. "warehouse open 8-5 Eastern time"), in which case it should be part of the configuration for that one service.

Re: How setting the TZ environment variable avoids thousands of system calls

#134

Post by deathanatos »

vesinisa wrote: post #118
deathanatos wrote: post #115

Earlier quoted context omitted.

This isn't a typo, but is part of the syntax used by the TZ variable. (The same format appears in the article itself.) See `man timezone` on a Linux system[1]. Specifically, see the passage that I've quoted below. Note that this is the third of three different formats that the man page describes that you can use in TZ: > The second format specifies that the timezone information should be read from a file: :[filespec]…

Sure, but at least on none of my Linux systems there is no such file /etc/localhost. I think the parent was referring to /etc/localtime. Not sure what is the behaviour if non-existent file is specified - perhaps the "value cannot be interpreted" case applies, but it's not pefectly clear, since it could be argued that the value is valid, just refers to a non-existent file.

Ah, correct you are! :-) I had missed that myself, and the : syntax is so rarely seen I naturally assumed that was what was intended.

Re: How setting the TZ environment variable avoids thousands of system calls

#135

Post by deathanatos »

lfowles wrote: post #131
deathanatos wrote: post #128

Earlier quoted context omitted.

> 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 definiti…

Sounds like a misunderstanding of "simple" :)

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).

Re: How setting the TZ environment variable avoids thousands of system calls

#136

Post by vsl »

deathanatos wrote: post #128
lfowles wrote: post #122

Earlier quoted context omitted.

>Breaking a seconds-since-epoch out into year/mo/day/etc. is "simple" math, and shouldn't require a filesystem access. To do it simply yes, but not correctly. See the "Falsehoods programmers believe about time" series. http://infiniteundo.com/post/25326999628/falsehoods-programm... http://infiniteundo.com/post/25509354022/more-falsehoods-pro...

> 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 definiti…

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.

Re: How setting the TZ environment variable avoids thousands of system calls

#138

Post by barrystaes »

Im not an expert but the first thing that comes to mind is that 1) TFA does not quantify the performance gain in time 2) I wonder if environment variables like TZ are a security risk/vector in that these might facilitate attackers to stealthy skew/screw time within current user process... no root required.

Re: How setting the TZ environment variable avoids thousands of system calls

#139

Post by tripzilch »

Symbiote wrote: post #39
kseistrup wrote: post #35

Earlier quoted context omitted.

What I meant was: Currently my timezone is CET. In a month's time it will be CEST. If I have to set TZ to explicitly mirror that it will be a burden.

TZ may be set like this: TZ=:Europe/Copenhagen Replace Europe/Copenhagen with the appropriate entry from the list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones Usually, /etc/localtime is a symlink, as on my laptop: /etc/localtime -> /usr/share/zoneinfo/Europe/Copenhagen so TZ=:/etc/localtime has the same result. You can demonstrate that it takes account of changes to timezones: Normal time for London:…

wait, so when I did `echo $TZ`, to check, and got `Europe/Amsterdam` that means it's already properly and I did't need to set it to `:/etc/localtime`?

this is not a part of Linux I'm very familiar with

Re: How setting the TZ environment variable avoids thousands of system calls

#140

Post by geofft »

curlypaul924 wrote: post #123
geofft wrote: post #64

Earlier quoted context omitted.

It's hard to do that without any system calls, though. The way you'd do this is to open an inotify (or platform equivalent) file descriptor on the first call to localtime(), and on future calls, only bother statting /etc/localtime again if that file descriptor reports something has changed. But checking if an FD has data requires a system call; you'd do a non-blocking read on the FD (or a non-blocking select or poll,…

What about calling mmap to map /etc/localtime into memory? The file would still have to be parsed for every call to localtime(), but the system call is avoided. (Better yet, if it were possible to memory-map the directory entry for /etc/localtime, parsing could be avoided as well). I agree the best solution is to provide a more sensible API. Why should an application be limited to only _one_ timezone?

I think I like that solution! It doesn't work if someone replaces /etc/localtime with a new file, but it works if they update it in place. It's low-overhead as long as /etc/localtime remains in cache; the process that updates it will write to the same pages. It's pretty high-overhead if /etc/localtime ever gets flushed from cache, though, since you have to go out to disk.
Post reply on HN