bokmann
BusinessTime::Config.time_zone
This separates BusinessTime time zone from the global Time.zone configuration. By default, it still pulls directly off Time.zone, but it can be changed separately.
I'm curious - what is the use case for having business time follow a different time zone than the application itself? This feels like an odd complexity/duality to have to think about, given I'm striving for keeping the complexity of this code around the essential comlexity necessary for dates and hours...
The main reason for us is tech debt of not configuring timezones correctly... I completely understand if you don't want this kind of implementation, but it was a quick enough hack.
However, it'd be nice to be able to calculate business days in different contexts (i.e. business time in both New York and London).
First, I'm sorry for the delay in dealing with this. Businesstime has been working fine for my purposes and I haven't had the headspace to get an understanding of some other people's use cases.
I just released 0.7.4, and need to release 0.8.0 with 2.2.0 support (and feature parity). Then I'll take care of the few outstanding pull requests for a 0.8.1.
I appreciate the quality of this pull request - nice comments, tests, and everything. I'm not sure I want to add the complexity of supporting a different time zone than the main application; I have a got feeling that if we do that, we'll end up with other people's edge cases of differing time zones from user input, the database, date calculations, etc. and that is the kind of complexity I tend to spend my career grooming out of applications.
As mentioned in other contexts, I trying not to support time zone configuration by request, and the 'nice to have' of timezone in different contexts might encourage more of that.
This PR could be useful for cases where code is UTC only but your test can run on developers machine which are not set to UTC. In this case, it is very easy to get tests passing on the CI (in UTC) but not on workstations.
