Day 1

I've been having some awful graphics issues lately. Today, I decided to take a 10 minute break and update the drivers. That decision cost me about 6 hours while I pounded my fists in frustration trying to make these silly ATI proprietary drivers work. Finally, after a (should have been) obvious revelation, I discovered I was using Ubuntu 8.04 instead of 8.10. Good catch there, Marty. Anyway, problem solved - crisis averted. On to the research.

This is my first week working on a Summer of Code project, so I'll be logging a little more frequently here. I've decided to spend most of the day that I wasn't fiddling with graphics settings on researching gregorian versus POSIX date implementations. A gregorian temporal datatype would store the number of days since January 1st, 1 AD, which is how the TimeSeries module works. The POSIX implementation (also known as Unix Time) would store the number of seconds since the epoch: January 1st, 1970. As of this time, my proposal uses the POSIX (Unix) implementation. My lingering concern is the range of dates. Which implementation would give me a larger, faster, more accurate, and more useful range of dates? More on this tomorrow, I guess.

Unix Time does not count leap seconds.

A leap second is a positive or negative one-second adjustment to the Coordinated Universal Time (UTC) time scale that keeps it close to mean solar time.
-Wikipedia

So the UTC time scale was implemented to keep a very accurate time approximation. Days in the UTC time scale have 24 hours, which have 60 minutes, which usually have 60 seconds, but sometimes have 59 or 61 (Wikipedia). Most days in the UTC time scale have 86,400 seconds. This will give pretty accurate approximations for times.

Leap seconds are necessary because we don't measure time by the rotation of the earth. We measure the frequency of the caesium-133 atom changing states (or something). This method has produced an incredibly accurate representation of time (down to 10^-9 seconds per day) and it's a lot easier than trying to find some Archimedean Point to observe the rotation of the earth. It's a lot easier to put a tiny thing in a test tube than to put a planet in a test tube.

There have been lots of different designs for how to store and compute time intervals. Luckily for my proposal, this type of thing has been done lots of times before me. Rather than reinvent the wheel, I can rest on a sound foundation. Lots of databases depend on time storage. I'll have to be checking those out tonight or tomorrow. But my main focus here isn't storage; it's computation. I need to provide quick and easy computation with something as complex as a date or a time interval.

Also, due for this week is the base creation of both datetime64 and timedelta64. Just the basic creation. Next week I'll worry with compatibility between the other Python Datetime. Hopefully, I can borrow some of the timeseries code.