Geek Clock: They can do Better

Let's start at 1 o'clock and work our way around in a clockwise fashion.

• tan π/4 would be cleaner.
• round(∏) is fine, but how about ⌊π⌋ instead?
• Log 55 is ambiguous, misleading, and inexact--and who capitalizes a log function? Most people will assume the base is 10, except computer scientists might first think 2. But clearly this is intended to be natural log. So, why not say what you mean? ln 55.  For precision, this could be wrapped in a floor function. So, my suggestion: ⌊ln 55⌋
• 16/2 is boring. How about 2³ instead?
• Similarly, 3x3 would be better-written 3².
• g? Do they mean 9.8 m/s/s? How about 12₈?
• For 11, is that 0b? 06? Make it clear: 0xb or b_16. Add a leading zero if you want--I don't care.
• 1100₂ is fine for 12.

Java's java.util.Date Class

Teaching Java programming to novices forces me to sometimes revisit the basics in my own understanding, or the edges of what I understand.

java.util.Date has come up a couple times this semester, and I thought I would verify the behavior of Date for dates at and before 1970-01-01. Here's my simple test code:

//Time-stamp: <2014-02-17 11:14:34 jdm>

import java.util.Date;

public class TimeZero {

  public static void main(String[] args) {

    final int yearsAgo = Integer.parseInt(args[0]);

    final double msAgo = yearsAgo

      * 365.25 // days per year

      * 24     // hours per day

      * 60     // minutes per hour

      * 60     // seconds per minute

      * 1000;  // ms per second

    final Date d = new Date((long) -msAgo);

    System.out.println(d);

  } // main()

} // class TimeZero

I'm neglecting leap seconds in my calculation of ms before 1970-01-01 (called msAgo). Assuming that a year averages 365.25 days is also not quite right, but since 2000 was one of those leap years divisible by 400, it's pretty close for recent years. Providing zero as input acts as expected (once one takes the time zone difference between here and Greenwich into account):

> java TimeZero 0

Wed Dec 31 19:00:00 EST 1969

Three years earlier seems to be about right, given that 1968 was a leap year:

> java TimeZero 3

Sun Jan 01 01:00:00 EST 1967

1000 years before 1970 looks good:

> java TimeZero 1000

Sat Dec 18 19:00:00 EST 969

Let's look around near the beginning of CE and the end of BCE (boundary conditions):

> java TimeZero 1967

Tue Dec 19 01:00:00 EST 2

> java TimeZero 1968

Sun Dec 18 19:00:00 EST 1

> java TimeZero 1969

Sat Dec 18 13:00:00 EST 1

This seems odd, but the Gregorian calendar does not have a year zero (see https://en.wikipedia.org/wiki/Gregorian_calendar) and Date.toString() does not include CE/BCE indication. I played around with calendars in my locale to get the era, but cal.get(Calendar.ERA) returns an int, which makes no sense whatsoever, and the problem isn't interesting enough to spend more time on.

However, I am willing to say the Java Date and Calendar hierarchies are entirely too complicated for day-to-day uses. This is one of the few places where I endorse using non-standard class libraries.

NTP in Linux Mint 12

It appears my Mint system is using NTP, but the reason I'm even thinking of this is that my system clock seems to be drifting.

The Mint User's Guide (still Mint 11 at the main site) has no mention of NTP, nor of "Network Time," the vague label used in the Date and Time settings. Dumbing down the interface by labeling what I suspect is NTP as "Network Time" is not helpful, especially if it's not documented. Someone who understands networking is left wondering if this is NTP. Someone who doesn't understand networking will have no clue what the "Network Time" switch is for:

Now I have to dig into the configuration files if it turns out I care enough.