Forum: Ruby on Rails Scheduling in Ruby on Rails

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
06f1fc5cb35a5f5e23f048ac35422c92?d=identicon&s=25 Ian Piper (Guest)
on 2009-03-02 11:05
(Received via mailing list)
Hi all,

I hope someone can point me in the right direction. I am looking for
some sample code to help with writing some code for scheduling
maintenance for machinery. The idea is that, like a car, this
machinery needs maintenance either at certain intervals or after a
certain number of hours of use (whichever is sooner). I am not sure
how best to manage the time measurements (DateTime or Time?) or how to
build the business rules to do the measurements and comparisons
robustly.

I wondered whether anyone here could direct me to an example.

Thanks,


Ian.
--
80e4cb97cae5c8d745f72337d93fd8f2?d=identicon&s=25 MaD (Guest)
on 2009-03-02 11:22
(Received via mailing list)
it all depends on your machine. nobody can tell you what's right (or
even the best) for you. you gotta decide for yourself.

to show you some alternatives:
- you could just work with cron-jobs.
- you could use backgrounDRb or workling/starling to schedule your own
processes.
988320371d9a18f0d50375188e01d54a?d=identicon&s=25 Peter Vandenabeele (Guest)
on 2009-03-02 11:29
(Received via mailing list)
On Mon, Mar 2, 2009 at 10:50 AM, Ian Piper <ianpiper@gmail.com> wrote:
> I am not sure
> how best to manage the time measurements (DateTime or Time?) or how to
> build the business rules to do the measurements and comparisons
> robustly.
>
> I wondered whether anyone here could direct me to an example.

If you don't need increments smaller than 1 day, I prefer to use the
Date class.
I find it easier than Time to work with:
* no ambiguity over "now" being a different date in different time zones
etc
* easier to compare date_1 == date_2

  http://ruby-doc.org/stdlib/libdoc/date/rdoc/classe...

A few simplistic examples:

>> date = Date.today
=> Mon, 02 Mar 2009
>> next_month = date + 1.month
=> Thu, 02 Apr 2009

>> date = Date.new 2009,01,31
=> Sat, 31 Jan 2009
>> next_month = date + 1.month
=> Sat, 28 Feb 2009 # automatic rounding down to valid date

>> date = Date.new 2008,02,29
=> Fri, 29 Feb 2008
>> next_year = date + 1.year
=> Sat, 28 Feb 2009 # automatic rounding down to valid date
>> four_years_later = date + 4.year
=> Wed, 29 Feb 2012

Always be careful with comparing dates near the end of the months
as months have a variable length.

Easier comparison of date_1 == date_2  (compared to time_1 == time_2)

>> date_1 = Date.today
=> Mon, 02 Mar 2009
>> date_2 = Date.today
=> Mon, 02 Mar 2009
>> date_1 == date_2
=> true
>> time_1 = Time.now
=> Mon Mar 02 11:24:59 +0100 2009
>> time_2 = Time.now
=> Mon Mar 02 11:25:06 +0100 2009
>> time_1 == time_2
=> false

HTH,

Peter
06f1fc5cb35a5f5e23f048ac35422c92?d=identicon&s=25 Ian Piper (Guest)
on 2009-03-02 12:06
(Received via mailing list)
On 2 Mar 2009, at 10:28am, Peter Vandenabeele wrote:

> If you don't need increments smaller than 1 day, I prefer to use the
> Date class.
> I find it easier than Time to work with:
> * no ambiguity over "now" being a different date in different time
> zones etc
> * easier to compare date_1 == date_2
>
>  http://ruby-doc.org/stdlib/libdoc/date/rdoc/classe...

Thanks Peter,

Those are good examples. You mention using Date for increments that
are not smaller than one day. In fact my situation is a hybrid, since
the machinery may be running at intervals over several days (so I
would need to track a usage event that spans days) but I need to
record the total number of hours of use during that time. From what I
can see the DateTime class allows for this. I suppose what I am really
asking here is under what circumstances would I use the Time class:
using DateTime always gives me more information doesn't it?


Ian.
--
This topic is locked and can not be replied to.