Ultimate API - Timestamps

[Ally]

Simple suggestion: Move unix timestamps from uint32 to uint64 or 256.

Edit:
Actually someone please explain to me why unix timestamps are in seconds(??) but the delay is in milliseconds. Makes 0 sense.

 

[Harry]

Simple suggestion: Move unix timestamps from uint32 to uint64 or 256.

On the API side, all timestamps are parsed as u64s currently so I'm not quite sure where you're referring to regarding this.

Actually someone please explain to me why unix timestamps are in seconds(??) but the delay is in milliseconds. Makes 0 sense.

I assume you're referring to the Retry-After header for rate-limiting errors? If so, we have a burst limit set so seconds just weren't granular enough for this.
Plus, it's not a timestamp so I don't really see that being inconsistent with the rest of the API.

 

[Ally]

On the API side, all timestamps are parsed as u64s currently so I'm not quite sure where you're referring to regarding this.

In the docs, uint is specified. uint is definitely not uint64 (e.g. uint32 vs uint64).

 

[Harry]

In the docs, uint is specified. uint is definitely not uint64 (e.g. uint32 vs uint64).

That's just referring to an unsigned integer, not specific to any language.
It's just meant to be a pseudocode-esque/abstract definition of the objects.

Some languages obviously don't have any concrete definition of 32bit vs 64bit ints, so for some who've only used those sorts of languages, it might be confusing.
Equally, I could just note at the top of the page that all ints need to fit within the 64bit space.

Realistically though, I don't think any practical use of the API will yield ints outside the 32bit space (64 bit is more of a precaution, for instance, user IDs are maxed 10 digits by definition).