bigbluebutton-api-ruby
bigbluebutton-api-ruby copied to clipboard
Recordings dates with incorrect time zones
Example response from BBB (0.8) has this information:
<startTime>Mon Apr 09 17:40:55 YEKT 2012</startTime>
but :startTime param will have this value:
1.9.3-p0 :023 > t=$bigbluebutton_api.get_recordings(:meetingID=>meeting.id)[:recordings][0][:startTime]
=> Mon, 09 Apr 2012 17:40:55 +0000
I wrote small monkey patch for this issue:
module BigBlueButton
class BigBlueButtonFormatter
# converts a value in the @hash to DateTime
def to_datetime(key)
unless @hash.has_key?(key) and @hash[key]
nil
else
# BBB >= 0.8 uses the unix epoch for all time related values
# older versions use strings
# a number but in a String class
if (@hash[key].class == String && @hash[key].to_i.to_s == @hash[key])
value = @hash[key].to_i
else
value = @hash[key]
end
if value.is_a?(Numeric)
result = value == 0 ? nil : DateTime.parse(Time.at(value/1000.0).to_s)
else
if value.downcase == "null"
result = nil
else
result = Time.parse(value).to_datetime #this line has been changed
end
end
@hash[key] = result
end
end
end
end
And now:
1.9.3-p0 :002 > t=$bigbluebutton_api.get_recordings(:meetingID=>meeting.id)[:recordings][0][:startTime]
=> Mon, 09 Apr 2012 17:40:55 +0600
Hi rap-kasta, thanks for the report. I'll test it when I get some time and fix the gem.
@rap-kasta I'm not sure if Time.parse
is the solution. Take a look at these examples:
ruby-1.9.2-p290 :008 > Time.parse("Mon Apr 09 17:40:55 UTC 2012")
=> 2012-04-09 17:40:55 UTC
ruby-1.9.2-p290 :005 > Time.parse("Mon Apr 09 17:40:55 YEKT 2012")
=> 2012-04-09 17:40:55 -0300
The second one shows the problem. I tried to parse the string in your example but it doesn't parse the timezone correctly. It shows -0300, my local timezone.
But anyways, since BBB 0.8 beta4 getRecordings
returns a timestamp, just like the other API calls. See: https://groups.google.com/d/msg/bigbluebutton-dev/StwQdDF6bdA/FQ5oO9G8bSYJ
So I'll probably just remove the parsing of strings, we won't need it anymore.
Oops, I guess it's better to maintain the parsing of strings so BBB 0.7 will still be supported.
I've tried a more specific parsing method that should behave better, but still the timezone YEKT is not identified:
1.9.2p290 :019 > DateTime.strptime("Mon Apr 09 17:40:55 UTC 2012", '%a %b %d %H:%M:%S %Z %Y')
=> Mon, 09 Apr 2012 17:40:55 +0000 -- OK
1.9.2p290 :020 > DateTime.strptime("Mon Apr 09 17:40:55 EST 2012", '%a %b %d %H:%M:%S %Z %Y')
=> Mon, 09 Apr 2012 17:40:55 -0500 -- OK
1.9.2p290 :021 > DateTime.strptime("Mon Apr 09 17:40:55 PST 2012", '%a %b %d %H:%M:%S %Z %Y')
=> Mon, 09 Apr 2012 17:40:55 -0800 -- OK
1.9.2p290 :017 > DateTime.strptime("Mon Apr 09 17:40:55 YEKT 2012", '%a %b %d %H:%M:%S %Z %Y')
=> Mon, 09 Apr 2012 17:40:55 +0000 -- NOT OK