Bplotka 1823ae8bc4 Fixed int64 overflow for timestamp in v1/api parseDuration and parseTime (#2501) ... * Fixed int64 overflow for timestamp in v1/api parseDuration and parseTime This led to unexpected results on wrong query with "(...)&start=148966367200.372&end=1489667272.372" That query is wrong because of `start > end` but actually internal int64 overflow caused start to be something around MinInt64 (huge negative value) and was passing validation. BTW: Not sure if negative timestamp makes sense even.. But model.Earliest is actually MinInt64, can someone explain me why? Signed-off-by: Bartek Plotka <bwplotka@gmail.com> * Added missing trailing periods on comments. Signed-off-by: Bartek Plotka <bwplotka@gmail.com> * MOved to only `<` and `>`. Removed equal. Signed-off-by: Bartek Plotka <bwplotka@gmail.com>		2017-03-16 15:16:20 +01:00
..
api/v1	Fixed int64 overflow for timestamp in v1/api parseDuration and parseTime (#2501)	2017-03-16 15:16:20 +01:00
ui	Adding version to names of static files	2017-03-03 23:36:06 +03:00
federate.go	web: add error counter for federation responses	2016-12-06 16:09:50 +01:00
federate_test.go	web: add more federation test scenarios	2016-09-15 15:23:55 +02:00
web.go	Use revision as cachebuster	2017-03-07 18:03:52 +03:00
web_test.go	Add missing license headers	2016-04-13 16:08:22 +02:00