1.0.0 impl: various datetime fixes

[bates64]

• Updated message datetime keys as per spec (more consistent with the rest of the API):
  • message.date -> message.dateCreated
  • message.editDate -> message.dateEdited
  • Updates tests to reflect
• Fix #297
  • We now store dates to millisecond-level accuracy, however the serialize functions floor the value before they are outputted by the API.
  • This fixes some tests.
  • We may want to get the spec to specify whether these dates should always be integers (what we're doing now) or may be floats.
  • Note that currently the API specifies "number" as the type. This is ambiguous, and we should probably use 'integer' and 'float' across the entire spec if applicable.

[towerofnix]

We now store dates to millisecond-level accuracy, however the serialize functions floor the value before they are outputted by the API.

Why?

We're a chat service. This means people send messages quickly - very often multiple times in a single second. Why should we prevent the user (or developers) from knowing the order of messages that came within a single second?

I know that some languages have int types which are separate from floats, but they can just convert the values to integers, if they really need to.

[bates64]

Why should we prevent the user (or developers) from knowing the order of messages that came within a single second?

Unix time is standard. Date.now() is not. The milliseconds float thing should be specified in the API as a recommended (but not required) practice imo. Serialize shouldn't floor :+1:

[PullJosh]

How many programming languages do not give a way to tell the current millisecond?

When we write a server implementation in BF, we'll have a bit of thinking to do...