MATLAB seems to have a very peculiar notion on how to represent dates
and times. Yesterday I spent a wonderful couple of hours debugging
some code that’s supposed to compute the sun’s position, most of which
could have been avoided if the MATLAB designers had followed a simple
convention used by, I believe, most computing platforms.

In MATLAB, dates and times are represented internally by a so-called
*serial date number*, defined as the number of time units counted
since a given reference date. If you are like me you will, I suppose,
assume that this reference date is the standard UNIX *epoch*,
i.e. midnight, January 1st, 1970. Well you’re only about two millenia
off—the reference date in MATLAB is the hypothetical (and
non-existent) date of midnight, January 1st, 0000. Never mind that
there never was a year 0000—the calendar goes straight from 1 BC to
1 AD.

And if you *really* are like me you will of course assume that the
unit of time in which this serial date number is counted is seconds,
or at least milliseconds. Wrong again—MATLAB choosed *days* as its
fundamental unit of time. And of course, Octave was forced to follow
MATLAB’s choice:

octave:4> format long
octave:5> now
ans = 734313.962094548

Besides making it much more difficult to make MATLAB interoperate
with, say, Java libraries, there are several problems with this
approach (documented in Octave’s help file, haven’t checked in
MATLAB):

1. The Julian calendar is ignored, so anything before 1582 will be
wrong;
1. Leap seconds are ignored. In other words, MATLAB ignores days that
happened to be 86401 seconds long (yes, there are).

When working with timeseries data, in particular climate data, I
always try to count time from the UNIX epoch—ideally as the number
of seconds from the epoch, the way `date(1)` works when called with
the `+%s` format argument:

18:08:49@netbook$ date +%s
1277309333
18:08:53@netbook$ date +%s
1277309336

In Java, `System.currentTimeMillis()` will return the number of
milliseconds since the epoch:

scala> System.currentTimeMillis
res0: Long = 1277395240485

In R, converting a `DateTime` object to numeric yields the number of
seconds:

> as.numeric(Sys.time())
[1] 1277310008

In short, every computing platform I’ve touched in the recent weeks
represents time starting from the standard UNIX/POSIX epoch, and
always do so in a unit related to seconds. In other words, there is no
justification for MATLAB’s decision to represent time since year 0000,
and even less for doing so in number of days. I don’t mean to bash
MATLAB (well… a bit, maybe). I just regret that anytime I need
MATLAB to interoperate with some other code, I need to include a factor
of 86400 and shift everything by 1970 years.