GELF spec 1.2

The GELF spec states the following about the `timestamp` field.

> UNIX microsecond timestamp; SHOULD be set by client library. Will be set to NOW by server if absent.

The GELF parser in graylog2-server parses the `timestamp` field of incoming messages like this:

``` java
double messageTimestamp = doubleValue(json, "timestamp");
DateTime timestamp;
if (messageTimestamp <= 0) {
timestamp = Tools.iso8601(); // current time
} else {
// we treat this as a unix timestamp
timestamp = Tools.dateTimeFromDouble(messageTimestamp);
}

...

/*
* The double representation of a UNIX timestamp with milliseconds is a strange, human readable format.
*
* This sucks and no format should use the double representation. Change GELF to use long. (zomg)
*/
public static DateTime dateTimeFromDouble(double x) {
return new DateTime(Math.round(x*1000), DateTimeZone.UTC);
}
```

All of the client libraries we checked use something like this for the timestamp:

``` java
double timestamp = logEvent.getTimeStamp() / 1000.0;
```

So in reality the `timestamp` field is a UNIX timestamp in **seconds** with optional **milliseconds** after the decimal point.

That means that either the GELF 1.1 specification is wrong or everyone (including ourselves) implemented it incorrectly.

Two suggestions:
1. Adjust the `timestamp` field specification to match reality: "Seconds since UNIX epoch; SHOULD be set by client library. Will be set to the current system time by server if absent.".
2. Add an optional `timestamp_ms` field which holds a millisecond timestamp. If `timestamp_ms` exists in an incoming message, that one should be used as timestamp.

This ensures backwards compatibility with existing clients but also allows fine resolution timestamps to be sent.

Any comments? Any other changes for a version 1.2 of the GELF spec?