Must add UTC time offset to Querys in order to get any results

[hjtran]

Environment details

• OS type and version: MacOS Catalina 10.15.7
• Python version: 3.9.2
• pip version: 21.3.1
• google-cloud-monitoring version: 2.9.1
• Timezone: EDT

Steps to reproduce

Querying metrics, I have to add at least 4 hours (the time offset to UTC from EDT) in order to get any results. Here's the code I ran into it with

def get_num_nacked_messages(subscription_path) -> int:
    client = _get_metrics_client()
    subscription_name = subscription_path.split('/')[-1]
    q = query.Query(
        client,
        PROJECT_ID,
        'pubsub.googleapis.com/subscription/num_undelivered_messages',
        minutes=241).select_resources(subscription_id=subscription_name).as_dataframe()
    count = q['pubsub_subscription'][PROJECT_ID][subscription_name][-1]
    return count

This will only return anything if minutes>=241 (or the equivalent w/ other units of time) and the subscription exists.

This is of course very confusing and for the longest time I couldn't figure out why on my local machine I couldn't see some metrics data but my server on UTC time could using the exact same code.

I'm guessing this has to do with some naive vs non-naive UTC time.

Additional notes from my own debugging

I think there might be something up at the stage where TimeInterval converts the end_time/start_time into a DatetimeWithSeconds.

I executed these within a minute of each other:

>>> from google.cloud.monitoring_v3 import types
>>> datetime.utcnow().replace(tzinfo=timezone.utc) # This time is correct
datetime.datetime(2022, 6, 21, 12, 8, 25, 837972, tzinfo=datetime.timezone.utc)

>>> types.TimeInterval(end_time=datetime.utcnow()).end_time
...
DatetimeWithNanoseconds(2022, 6, 21, 16, 8, 42, 128032, tzinfo=datetime.timezone.utc) # This time is 4 hours in the future

I confirmed the above lines on another person's Macbook (though using py3.8). I'm wondering if there's some kind of misunderstanding on my part or something not documented since I would expect that this bug would come up for a lot of people.

Possible Fix: A fix that works for both my UTC machine and my EDT machine is to use end_time=datetime.now(tz=timezone.utc) (which is what's recommended in the docs for utcnow).

[parthea]

I'm going to transfer this issue to the google-cloud-python repository as we are preparing to move the code for google-cloud-monitoring to that repository in the next 1-2 weeks.