Too Cool for Internet Explorer

Saturday, April 10, 2010

Who cares about a nanosecond?

Things are going faster and faster, so, why still measuring times in a second precision?

Could you think about how many files are uploaded from users in a specific city within a second?

Let’s say, any country capital with a high speed broadband service.

Try to put them all in order. Which arrives first?

Most of the current relational databases support Timestamp data:

Oracle ........ '2007-08-08 09:00:00.123456789'
DB2 ........... '2002-10-20-'
PostgreSQL .... '2003-07-29 13:19:30.532'
MySQL ......... '1970-01-01 00:00:00'

But most of it doesn’t consider nanoseconds properly.

People tend to consider that only Real Time Systems have better precision of time measurement needs, but that is not true.

I have recently developed a business application where users can upload files.

Files are uploaded in groups (fifteen maximum). It was important to know the order on which files have been upload.

Depending on the size of the files and users’ internet broadband capacity, some files could be uploaded in the same second.

So, that is the reason to store the uploaded date in the table as a Timestamp column.

The problem starts when trying to feed the required data using the language resources only. I know we can provide current timestamp from the database itself, but if you are not using a relational database and needs to store the timestamp?

Java and Python for instance, have nanoseconds support, but deal with them separately from the date and time. And about Ruby?

The Good new is that Ruby 1.9 does the job nice this way:'%Y-%m-%d-%H:%M:%S.%6N')

Where you can specify the desired precision in %3N, %6N or %9N, but will need a superfast machine to test them all.

Here is a working sample:

Another consideration you must take into account: the O.S. used:

  • Solaris and Linux already support nanosecond precision.
  • The situation on Mac OSX is not that good, since only microseconds are available.
  • Windows, on the other hand, supports nanoseconds, but have a 10ms granularity limit.

So, depending on O.S. running your code, you may need some extras to get the timestamp in the complete form.

The Bad new is that Ruby 1.8 doesn’t support nanoseconds.

Back to the real World, we must admit that most of people out there are using Ruby 1.8.6 under Windows.

So, I have made a working snippet for Ruby 1.8.6 on Windows that could at least, provide data to the PostgreSQL centisecond format.