alindeman / zonebie Goto Github PK

View Code? Open in Web Editor NEW

422.0 7.0 15.0 112 KB

Zonebie prevents bugs in code that deals with timezones by randomly assigning a zone on every run

License: MIT License

Ruby 100.00%

timezone ruby

zonebie's Introduction

Zonebie

Zonebie prevents bugs in code that deals with timezones by randomly assigning a zone on every run.

If Zonebie helps trigger a timezone-related bug, you can temporarily assign the ZONEBIE_TZ environment variable to make your tests deterministic while you debug (more information below).

Requirements

MRI (2.0.x, 2.1.x, 2.2.x, 2.3.x, 2.4.x)
JRuby (1.7)
Rubinius (3.x)

And either of these gems which adds timezone support to Ruby:

activesupport >= 3.0 (Rails 3.0, 3.1, 3.2, 4.0, 4.1, 4.2)
tzinfo >= 1.2

Installation

If using Bundler (recommended), add to Gemfile:

gem 'zonebie'

Usage with Rails & Active Support

Active Support allows setting a global timezone that will be used for many date and time calculations throughout the application.

Zonebie can set this to a random timezone at the beginning of test runs. Specifically for Active Support, it sets Time.zone.

Test::Unit & Minitest

Add to test/test_helper.rb:

Zonebie.set_random_timezone

RSpec

Add to spec/spec_helper.rb:

require "zonebie/rspec"

Cucumber

Add a file features/support/zonebie.rb with the following contents:

Zonebie.set_random_timezone

Usage with TZInfo

Zonebie can use the tzinfo gem, allowing it to work outside of Active Support (Rails).

However, Zonebie.set_random_timezone does not work outside of Active Support because there is not a concept of a global timezone setting. If you simply need a random timezone for some other part of your tests, Zonebie can help.

zone = TZInfo::Timezone.get(Zonebie.random_timezone)
puts zone.now

# Also works in Rails/Active Support
zone = ActiveSupport::TimeZone[Zonebie.random_timezone]
puts zone.now

Reproducing Bugs

When Zonebie.set_random_timezone is called, Zonebie assigns a timezone and prints a message to STDOUT:

[Zonebie] Setting timezone: ZONEBIE_TZ="Eastern Time (US & Canada)"

If you would rather that Zonebie not print out this information during your tests, put Zonebie in quiet mode before calling set_random_timezone:

Zonebie.quiet = true

To rerun tests with a specific timezone (e.g., to reproduce a bug that only seems present in one zone), set the ZONEBIE_TZ environment variable:

# Assuming tests run with simply `rake`
ZONEBIE_TZ="Eastern Time (US & Canada)" rake

Contributing

Fork it
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Added some feature')
Push to the branch (git push origin my-new-feature)
Create new Pull Request

zonebie's People

Contributors

Stargazers

Watchers

Forkers

highgroove jemadduxvault myror1 r38y davidbegin facerolling jasnow matsubo typeoneerror thiagogabriel benoitmc roman-franko fuelxc iq-scm

zonebie's Issues

README is unclear about system time zone vs AR time zone

To my limited understanding, there are two very different time zones in a Rails app:

The system time zone, overridable with ENV['TZ']
The ActiveRecord time zone, Time.zone, typically defaulted to UTC (config.time_zone in application.rb)

Zonebie seems to be setting the latter, but the README is really unclear about this.

On a general note, isn't it generally the case that in development teams, the different system time zones are the source of problems? Time.zone is fixed at UTC already.

Add Gemfiles for each of Rails 2.3, 3.0, 3.1 and 3.2

And make them run against Travis: http://about.travis-ci.org/docs/user/languages/ruby/ "Custom Bundler arguments and Gemfile locations"

Zonebie should not use TZ

Zonebie uses ENV['TZ'] as a way to override Time.zone (the ActiveRecord time zone). TZ is not a good choice for this, because it already designates the system time zone, which has nothing to do with the ActiveRecord time zone.

$ TZ=US/Pacific date; TZ=US/Eastern date
Wed Jul 11 07:48:30 PDT 2012
Wed Jul 11 10:48:30 EDT 2012

You can even change TZ while a Ruby app is running, and the updated value will be respected:

$ ruby -e "ENV['TZ'] = 'US/Pacific'; p Time.now; ENV['TZ'] = 'US/Eastern'; p Time.now"
2012-07-11 07:49:03 -0700
2012-07-11 10:49:03 -0400

Limit timezones for a specific country or group of zones?

Is it possible to provide a list of countries or timezones to focus the tests? I realize that timezone logic should work for any timezone, but the test suite "feels" weird having it test locations that the application was not designed to service.

It would be nice if one could pass a configuration block to Zonebie that includes a list of acceptable timezones and/or a list of countries that are supported."

License missing from gemspec

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Traveling around the world

I don't know about anybody else, but I feel like I'm traveling around the world every time I run my tests. This is great!

I was wondering if it would be worth including the first paragraph from wikipedia for each timezone so you can learn a bit while waiting for your tests to run.

For example, for Krasnoyarsk, we would pull the first paragraph (all above TOC) from http://en.wikipedia.org/wiki/Krasnoyarsk:

Krasnoyarsk (Russian: Красноярск, IPA: [krəsnɐˈjærsk]) is a city and the administrative center of Krasnoyarsk Krai, Russia, located on the Yenisei River. It is the third largest city in Siberia after Novosibirsk and Omsk, with a population of 973,826 (2010 Census).[8] Krasnoyarsk is an important junction of the Trans-Siberian Railway and one of Russia's largest producers of aluminium.

The city is notable for its nature landscapes; author Anton Chekhov judged Krasnoyarsk to be the most beautiful city in Siberia.[13]

I don't know, thought this might be kind of cool. I don't know how we would do it in an efficient manner. Maybe a second gem that just has these for each timezone? I'd hate to pull it down on every test run.

undefined method `random_timezone' for Zonebie

Please, don't remove public method from your API in minor updates.

[1] pry(main)> Zonebie.random_timezone
NoMethodError: undefined method `random_timezone' for Zonebie:Module

Zonebie should be able to iterate over every time zone

I am hesitant to use randomness in my tests, because sometimes a test would pass and then the next time I run it it would fail. If the test is truly failing because of time zone differences, that randomness would make it really hard to debug!

How about we add a way to iterate over every time zone? Something like this:

Zonebie.each_time_zone do |time_zone|
  #iterates through each ActiveSupport::TimeZone
  assert Something_in_the_db_is_always_in_UTC?
end