You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In riak_repl_wm_stats a UTC datetime is passed into httpd_util:rfc1123/1, which expects a local date. It causes the stats to blow up when clocks go forward for DST. rfc1123 takes a local datetime and throws an exception when you pass a datetime that sits within the mystical non-existent hour when moving clocks forward. It should be handled gracefully, and there's a patch in OTP 20.1 for it. But we should be passing in a local time anyway. The net result is that we lose the ability to monitor for an hour during this time period.
([email protected])1> Seconds = 63657709200. %% riak_core_util:moment() to produce current UTC seconds
63657709200
([email protected])2> Date = calendar:gregorian_seconds_to_datetime(Seconds).
2017,3,26},{1,0,0
([email protected])3> Formatted = httpd_util:rfc1123_date(Date).
exception error: no case clause matching []
in function httpd_util:rfc1123_date/1 (httpd_util.erl, line 344)
Fixed by converting to a local datetime with calendar:universal_time_to_local_time/1:
([email protected])13> Seconds = 63657709200. %% riak_core_util:moment() to produce current UTC seconds
63657709200
([email protected])14> Date = calendar:gregorian_seconds_to_datetime(Seconds).
2017,3,26,1,0,0
([email protected])15> DateLocal = calendar:universal_time_to_local_time(Date).
2017,3,26,2,0,0
([email protected])16> Formatted = httpd_util:rfc1123_date(DateLocal).
"Sun, 26 Mar 2017 01:00:00 GMT"
In
riak_repl_wm_stats
a UTC datetime is passed intohttpd_util:rfc1123/1
, which expects a local date. It causes the stats to blow up when clocks go forward for DST. rfc1123 takes a local datetime and throws an exception when you pass a datetime that sits within the mystical non-existent hour when moving clocks forward. It should be handled gracefully, and there's a patch in OTP 20.1 for it. But we should be passing in a local time anyway. The net result is that we lose the ability to monitor for an hour during this time period.Fixed by converting to a local datetime with
calendar:universal_time_to_local_time/1
:Think this is the same as described in basho/riak_core#773.
The text was updated successfully, but these errors were encountered: