give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "In order to best support AP PipelineTask conversion work at PCW2019, we need to have a Gen3 data repository for {{ap_verify_hits2015}} (or maybe {{ap_verify_ci_hits2015}}, or both?).    Anyhow, first step towards that is Gen3 Butler support for obs_decam, which is what this ticket is about.  That includes:   * Writing an [Instrument|https://github.com/lsst/daf_butler/blob/7220349561d794e99e523aff29bdb5c3bd80f379/python/lsst/daf/butler/instrument.py#L36] subclass for DECam.  The docs for the base class should tell you most of what you need to do (though I've just discovered they're not appearing in the Sphinx HTML for some reason), but I'm sure a concrete example will be even more useful, which [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/instrument.py#L50] provides.  Note that because this will be only the second {{Instrument}} subclass, it's probable we'll find we want to adjust the ABC-subclass boundary a bit.   * Writing a {{Formatter}} for raw DECam data (or if necessary, different formatters for different CCDs), probably by inheriting from [FitsRawFormatterBase|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/fitsRawFormatterBase.py#L29].  Once again, you can use [HSC|https://github.com/lsst/obs_subaru/blob/e6ea06fa94726c5b0f3c7e020223bbc1a58a2d70/python/lsst/obs/subaru/gen3/hsc/rawFormatter.py#L38] as an example.  This should do the same thing as the Gen2 CameraMapper's {{std_raw}} method.  A test that shows the kind of consistency we expect (for HSC) can be found in [ci_hsc_gen2 |https://github.com/lsst/ci_hsc_gen2/blob/tickets/DM-19817/tests/test_butlerShims.py#L81]- note that the Gen3 version generally tries much harder to clean things up and make things are components are internally consistent, so it may not be possible to make them entirely consistent with the Gen2 version.  We may not have a good place to put such a test for DECam until we're further along converting an actual test dataset, but it'd be great to write one for one-off testing now and attach it to this ticket, with the expectation that we'll put it in a CI'd package in the future.    After those steps (and after running the {{Instrument}} class's {{register}} method on a Gen3 repo), I think it should be possible to run the [Gen3 raw ingest task|https://github.com/lsst/obs_base/blob/master/python/lsst/obs/base/gen3/ingest.py] on DECam, and I consider that the end point for this ticket as long as any unexpected problems aren't huge.   This will rely a lot on the DECam translator in {{astro_metadata_translator}} as well as the above, but I think that's already working.    Note that there's no command-line driver script for that task yet, but it's pretty straightforward to run from an interactive Python prompt.  Given that we know that DECam has buggy boresight information in the headers, I don't expect it to populate the database with good spatial regions yet, and I'm okay with fixing that on another ticket (probably by using {{astro_metadata_translator's}} on-the-fly header-patching system to just fix the boresight values to something we've fit for the test data we care about).    Please ping #dm-middleware on Slack with any questions."
Answer: 49222.0