# ANN: ThirdBase 1.2.0 **URL:** \ **Category:** Ruby\ **Created:** [August 17, 2009, 11:30pm UTC](https://www.ruby-forum.com/t/ann-thirdbase-1-2-0/173899 "2009-08-17T23:30:55Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [August 17, 2009, 11:30pm UTC](https://www.ruby-forum.com/t/ann-thirdbase-1-2-0/173899/1 "2009-08-17T23:30:55Z")
ThirdBase is a replacement for Ruby’s standard Date/DateTime classes, with the following differences: - ThirdBase is roughly 2-10 times faster depending on usage - ThirdBase has a lower memory footprint - ThirdBase supports pluggable parsers - ThirdBase doesn’t depend on Ruby’s Rational class - ThirdBase always uses the gregorian calendar The 1.2.0 release of ThirdBase makes it much easier to add custom parsers. Custom parsers can now be specified via a strptime format string: DateTime.add\_parser(:us, ‘%Z %m~%Y~%d %S`%M`%H’) DateTime.parse(‘PDT 02~2009~28 15`45`12’) =\> #\ With a strptime-based parser, you don’t need to provide a block, as the parser block is created for you. You can still use the old Regexp-style parsers, and now they can return a Date/DateTime instance directly, they are no longer required to return a hash that is given to new!. An additional default parser was added so the following can be handled correctly: DateTime.parse(Time.now.to\_s) DateTime.parse(Time.now.strftime(‘%+’)) The named timezones supported by Ruby’s Time class are now supported by ThirdBase (e.g. PST, EDT, UTC). The %z strptime/strftime format string modifier now operates more closely to standard ruby. Enjoy, Jeremy - website {[http://third-base.rubyforge.org/](http://third-base.rubyforge.org/)} ---
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [August 18, 2009, 1:38am UTC](https://www.ruby-forum.com/t/ann-thirdbase-1-2-0/173899/2 "2009-08-18T01:38:54Z")
> ThirdBase is a replacement for Ruby’s standard Date/DateTime > classes, with the following differences: > > - ThirdBase is roughly 2-10 times faster depending on usage How does it compare to [http://tomayko.com/src/date-performance/](http://tomayko.com/src/date-performance/) ? Thanks. -r ---
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [August 18, 2009, 1:59am UTC](https://www.ruby-forum.com/t/ann-thirdbase-1-2-0/173899/3 "2009-08-18T01:59:14Z")
Roger P. wrote: > > ThirdBase is a replacement for Ruby’s standard Date/DateTime > > classes, with the following differences: > > > > - ThirdBase is roughly 2-10 times faster depending on usage > > How does it compare to [http://tomayko.com/src/date-performance/](http://tomayko.com/src/date-performance/) I haven’t used Date::Performance, but from reading that page, Date::Performance would certainly be faster as it is implemented in C. ThirdBase is pure ruby code. ThirdBase uses customizable regexp-based parsers as opposed to a fixed string scanning parser, so it is probably more flexible. I can’t comment in more detail without reading the Date::Performance code. Jeremy ---
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [August 18, 2009, 2:00pm UTC](https://www.ruby-forum.com/t/ann-thirdbase-1-2-0/173899/4 "2009-08-18T14:00:34Z")
On Mon, Aug 17, 2009 at 7:59 PM, Jeremy E.[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > ThirdBase is pure ruby code. > > ThirdBase uses customizable regexp-based parsers as opposed to a fixed > string scanning parser, so it is probably more flexible. > > I can’t comment in more detail without reading the Date::Performance > code. Both Date::Performance and ThirdBase seem to focus on the performance of datetime parsing. I took a quick look at the Date::Performance code, and it definitely is taking the approach of re-implementing a few key methods in C. I suspect that most of the performance comes from calling the Clib strptime routine, less so from the ‘ruby-inlined’ methods. In implementing RiCal [GitHub - rubyredrick/ri\_cal: New Rfc 2445 (iCalendar) gem for Ruby](http://github.com/rubyredrick/ri_cal/tree/master) my main performance problem with datetime was date time calculations. Because of the standard datetime implementation using a rational fraction to represent the time-of-day portion of a datetime the performance profiles were dominated by the gcd calculations needed to reduce rational numbers. So in my case I replaced the internal use of datetime instances with a custom class which uses a normal Ruby date and a fixnum representing the number of seconds since the beginning of the day, no C code, all ruby and much much faster for my purposes. But not at all a general replacement for datetime. – Rick DeNatale Blog: [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/) Twitter: [http://twitter.com/RickDeNatale](http://twitter.com/RickDeNatale) WWR: [http://www.workingwithrails.com/person/9021-rick-denatale](http://www.workingwithrails.com/person/9021-rick-denatale) LinkedIn: [http://www.linkedin.com/in/rickdenatale](http://www.linkedin.com/in/rickdenatale) ---
**Author:** ![nerdmaster](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/c68b51/32.png) [@nerdmaster](https://www.ruby-forum.com/u/nerdmaster)\ **Post date:** [August 18, 2009, 4:45pm UTC](https://www.ruby-forum.com/t/ann-thirdbase-1-2-0/173899/5 "2009-08-18T16:45:17Z")
Rick Denatale wrote: > Both Date::Performance and ThirdBase seem to focus on the performance > of datetime parsing. ThirdBase doesn’t just focus on parsing speed. It also tries to be fast to instantiate and fast for calculations. In addition to performance, ThirdBase also makes the parsers for Date.parse/DateTime.parse easily modifiable for the user. > I took a quick look at the Date::Performance code, and it definitely > is taking the approach of re-implementing a few key methods in C. I > suspect that most of the performance comes from calling the Clib > strptime routine, less so from the ‘ruby-inlined’ methods. > > In implementing RiCal [GitHub - rubyredrick/ri\_cal: New Rfc 2445 (iCalendar) gem for Ruby](http://github.com/rubyredrick/ri_cal/tree/master) > my main performance problem with datetime was date time calculations. > Because of the standard datetime implementation using a rational > fraction to represent the time-of-day portion of a datetime the > performance profiles were dominated by the gcd calculations needed to > reduce rational numbers. > > So in my case I replaced the internal use of datetime instances with a > custom class which uses a normal Ruby date and a fixnum representing > the number of seconds since the beginning of the day, no C code, all > ruby and much much faster for my purposes. ThirdBase takes a slightly different approach. It stores the date in whatever the input format is, converting only when necessary (which is why it is fast to instantiate). When it does need to do calculations, it generally converts to an integer julian day number and a Float representing the fraction of the day. > But not at all a general replacement for datetime. ThirdBase can be used as a general replacement. Not everything works the same way, but the differences are documented and won’t affect most code. Jeremy