+ def parse_browser_timestamp t
+ # Timestamps are displayed in the browser's time zone (which can
+ # differ from ours) and they come from toLocaleTimeString (which
+ # means they don't necessarily tell us which time zone they're
+ # using). In order to make sense of them, we need to ask the
+ # browser to parse them and generate a timestamp that can be
+ # parsed reliably.
+ #
+ # Note: Even with all this help, phantomjs seem to behave badly
+ # when parsing timestamps on the other side of a DST transition.
+ # See skipped tests below.
+
+ # In some locales (e.g., en_CA.UTF-8) Firefox can't parse what its
+ # own toLocaleString() puts out.
+ t.sub!(/(\d\d\d\d)-(\d\d)-(\d\d)/, '\2/\3/\1')
+
+ if /(\d+:\d+ [AP]M) (\d+\/\d+\/\d+)/ =~ t
+ # Currently dates.js renders timestamps as
+ # '{t.toLocaleTimeString()} {t.toLocaleDateString()}' which even
+ # en_US browsers can't make sense of. First we need to flip it
+ # around so it looks like what toLocaleString() would have made.
+ t = $~[2] + ', ' + $~[1]
+ end
+
+ utc = page.evaluate_script("new Date('#{t}').toUTCString()")
+ DateTime.parse(utc).to_time
+ end
+
+ if false
+ # No need to test (or mention) these all the time. If they start
+ # working (without need_selenium) then some real tests might not
+ # need_selenium any more.
+
+ test 'phantomjs DST' do
+ skip '^^'
+ t0s = '3/8/2015, 01:59 AM'
+ t1s = '3/8/2015, 03:01 AM'
+ t0 = parse_browser_timestamp t0s
+ t1 = parse_browser_timestamp t1s
+ assert_equal 120, t1-t0, "'#{t0s}' to '#{t1s}' was reported as #{t1-t0} seconds, should be 120"
+ end
+
+ test 'phantomjs DST 2' do
+ skip '^^'
+ t0s = '2015-03-08T10:43:00Z'
+ t1s = '2015-03-09T03:43:00Z'
+ t0 = parse_browser_timestamp page.evaluate_script("new Date('#{t0s}').toLocaleString()")
+ t1 = parse_browser_timestamp page.evaluate_script("new Date('#{t1s}').toLocaleString()")
+ assert_equal 17*3600, t1-t0, "'#{t0s}' to '#{t1s}' was reported as #{t1-t0} seconds, should be #{17*3600} (17 hours)"
+ end
+ end