Introducing month-serializer

Month::Serializer - Integer Serialization Plugin for Month Gem

Allows you to convert Month objects to Integer, and vice versa. This is useful for serializing Months into other data structures, like String, or to pass values in JSON, or send as parameters to Resque / Sidekiq jobs (which parameters are only compatible with simple JSON data types). Neither Date or Time can serialize properly to Resque/Sidekiq jobs.

Total Downloads Downloads Today Test Coverage Maintainability Network Stars Version Build Documentation Depfu Open Source Helpers Chat License: MIT

Why use Month instead of Date or Time?

  • Month is lighter weight
  • There are many situations where having Months incrementable by 1 is useful
    • directly mappable to iteration index
  • It facilitates month-based math.
    • epochal math like adding 48 months to June, 2018
    • monthly subscription logic
  • Adding a day when a day is not relevant can result in very overcomplicated systems that try to work around or ignore the stray days
    • data with a 1 month resolution


Add this line to your application’s Gemfile:

gem 'month-serializer'

And then execute:

$ bundle

Or install it yourself as:

$ gem install month-serializer


Add this to the bootstrapping process of your app, somewhere after the month gem is loaded. In Rails, config/initializers/month-serializer.rb would be perfect, but Rails is not required.

Month.send(:include, Month::Serializer)

This spec below, copied from the actual test suite, makes usage pretty clear. Note how the serialized Months as integer increment by one. If you think about counting time by months this makes sense. We often speak this way about babies, an 18 month old, or 24 month old.

How old is the Common Era right now? About 24.2k months! Is a millenimonth, millimes, or kilomonth, a thing? The Common Era is roughly 24 kilomonths old. 😆 And Neanderthal man went extinct about 495.6 = (471.4 + 24.2) kilomonths ago.

        -471359 =>, 1),  # hist: Extinction of Neanderthal
        24201 =>, 9),
        24202 =>, 10),
        # ...
        24214 =>, 10),
        24215 =>, 11),
        # ...
        24227 =>, 11),
        24228 =>, 12)
    }.each do |k, v|
           context "#{k} => #{v}" do
             it "Month converts to #{k}" do
               expect(v.to_i).to eq(k)          # to_i is added by this gem!
             context 'round trip' do
               it "can load #{k} to #{v}" do
                 expect(Month.load(k)).to eq(v) # load is added by this gem!
               it "can dump #{v} to #{k}" do
                 expect(Month.dump(v)).to eq(k) # dump is added by this gem!


After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to


Peter H. Boling of Rails Bling is the author.


See the Network View and the CHANGELOG


  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Added some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Make sure to add tests for it. This is important so I don’t break it in a future version unintentionally.
  6. Create new Pull Request

Bug reports and pull requests are welcome on GitHub at This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

Code of Conduct

Everyone interacting in the AnonymousActiveRecord project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.


This library aims to adhere to Semantic Versioning 2.0.0. Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, a new version should be immediately released that restores compatibility. Breaking changes to the public API will only be introduced with new major versions.

As a result of this policy, you can (and should) specify a dependency on this gem using the Pessimistic Version Constraint with two digits of precision.

For example in a Gemfile:

gem 'month-serializer', '~> 1.0', group: :test

or in a gemspec

spec.add_development_dependency 'month-serializer', '~> 1.0'
comments powered by Disqus