From a Linux terminal, if you need to find out what time it is in a different time zone or another country, you can use the date command. Just override the TZ environment variable when you run date:

[user@host ~]$ date
Mon Dec 14 22:10:59 CST 2015

[user@host ~]$ TZ=Poland date
Tue Dec 15 05:11:03 CET 2015

[user@host ~]$ TZ=Japan date
Tue Dec 15 13:11:07 JST 2015

[user@host ~]$ TZ=Australia/Melbourne date
Tue Dec 15 15:12:36 AEDT 2015

[user@host ~]$ TZ=Australia/Perth date
Tue Dec 15 12:12:41 AWST 2015

The full list of supported time zones will be somewhere on your filesystem; on many distributions, they're located at /usr/share/zoneinfo/. If you aren't sure where to find them, Wikipedia has a tz database that's mostly accurate.

Because some of the time zone names are cumbersome to remember and type, consider using aliases if you need to reference international times frequently. You can add commands ...

For a long time, I could do a packet capture on a Linux machine by redirecting the output of tcpdump to a file, and Ethereal would open it up no problem. Somewhere along the way, Wireshark started choking on these files. Every now and then I still forget and try to do something like this:

    tcpdump -nn -vv -S -X -s0 -i eth0 port 53 > /tmp/dns.cap

That captures a bunch of packets in human-readable form, but Wireshark refuses to open the file. It gives an error along the lines of:

    The capture file appears to be damaged or corrupt.
    (stanag4607: File has 976238138d-byte packet, bigger than maximum of 262144)

If you find yourself looking at this error, make sure to use the -w flag to tcpdump instead of redirecting stdout:

    tcpdump -nn -vv -S -X -s0 -i eth0 port 53 -w /tmp/dns.cap

This generates a binary pcap file that Wireshark happily opens up.

Given an error from chronyd that looks like this:

Sep 17 10:31:12 kitch chronyd[1355]: Could not write to temporary driftfile /var/lib/chrony/drift.tmp

The likely cause is that the filesystem where the driftfile lives (in this case /var) is full. Inspect the filesystem and free up some space.

I discovered by accident that PHP allows you to format the iterator in a for loop with sprintf(), as long as the result of sprintf() can evaluate to the same numeric type as your step value. As a contrived example, consider the following loop used to build out the options in a "months of the year" select list:

$month = '<select name="month">';
for ($i = 1; $i < 13; $i++) {
    $month .= '<option value="' . sprintf('%02d', $i) . '">' . sprintf('%02d', $i);
}
$month .= '</select>';

The same loop can be written this way:

$month = '<select name="month">';
for ($i = sprintf('%02d', 1); $i < sprintf('%02d', 13); $i = sprintf('%02d', ++$i)) {
    $month .= '<option value="' . $i . '">' . $i;
}
$month .= '</select>';

That is, the formatting of $i into a two-digit zero-padded integer is being done inside of the control block itself, instead of as a separate instruction inside the loop.

In this specific example, there's no benefit (and in fact there is some detri...