Transactions with UNIX timestamps #167
Conversation
unleashed
force-pushed
the
transactions-with-unix-timestamps
branch
5 times, most recently
from
ba86504
to
90b9f8e
Compare
Prior to this change, timestamps passed as part of a transaction to the report API were totally ignored. This change adds any non-default timestamps to the encode string to be sent to 3scale server. Requires 3scale version(s) 3.8+ See: 3scale/apisonator#167
unleashed
force-pushed
the
transactions-with-unix-timestamps
branch
from
90b9f8e
to
3cf3795
Compare
|
So... |
|
What? 😵 |
|
|
So I think the only reasonable way out of this surprising legacy from the past, especially given this is behaviour is not documented, would be to remove this offending test, since it does not make sense any way to do the negative testing (and even then it was so broken), and accept (for now) the discovery that completely broken timestamps like the one I specified can actually mean some random thing to the system, just the same way it's always been, and then consider whether to fix what was already broken adding validation. Ideas? |
|
@unleashed That sounds good to me 👍 |
…tamp parsing The current code uses Date._parse without proper validation, and while it correctly says '2012garbage2012' is not a date, it swallows the string '201210garbage201210' as a date. See #167.
unleashed
force-pushed
the
transactions-with-unix-timestamps
branch
from
3cf3795
to
5e9593a
Compare
|
So in the end I added a pending test that is way more likely to bug people when running the suite to go and fix this issue one way or another, and also changed the "negative" testing to look for changes in |
This allows us to take UNIX timestamps for transactions.
…NIX timestamps We had to disable some negative testing, ie. value 0 does not parse, and fix a value being tested that matched a UNIX timestamp, as well as being incorrect anyway for the negative test that was being executed right next after it.
…tamp parsing The current code uses Date._parse without proper validation, and while it correctly says '2012garbage2012' is not a date, it swallows the string '201210garbage201210' as a date. See #167.
unleashed
force-pushed
the
transactions-with-unix-timestamps
branch
from
5e9593a
to
78459a9
Compare
|
Is there something we can do about that? Have you taken a look to see if we can replace that @unleashed It'd be good to open an issue so we remember to address that. |
Maybe, but would certainly change more semantics - we can defer that to another PR. |
This adds support for specifying transaction timestamps as UNIX Epoch timestamps, ie. number of seconds since Jan 1, 1970.