Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amazon.CloudWatch.Model.MetricDatum timestamp is not set correctly #3329

Closed
mihneavelinOT opened this issue Jun 4, 2024 · 3 comments
Closed
Assignees
Labels
bug This issue is a bug. p2 This is a standard priority issue response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days.

Comments

@mihneavelinOT
Copy link

mihneavelinOT commented Jun 4, 2024

Describe the bug

Hello,

I am trying to send multiple metrics to CloudWatch using AWSSDK.CloudWatch NuGet via PutMetricDataAsync.
I am sending a List<MetricDatum>. When debugging, each MetricDatum has the TimestampUtc attribute set correctly(Timestamp attribute is the same -- I understand from the docs that this is the expected behavior).

When accessing the AWS Console, the datapoints are set wrong, setting the graph time to "UTC timezone" will show me the datapoint as happening with 3 hours before the TimestampUtc I set in the code!!!

Expected Behavior

To see the datapoints I sent at the correct timestamp in the graph.

Current Behavior

When accessing the AWS Console, the datapoints are set wrong, setting the graph time to "UTC timezone" will show me the datapoint as happening with 3 hours before the TimestampUtc I set in the code!!!

Reproduction Steps

Try sending a list of MetricDatum via PutMetricDataAsync function from AWSSDK.CloudWatch NuGet.

Possible Solution

No response

Additional Information/Context

No response

AWS .NET SDK and/or Package version used

AWSSDK.CloudWatch 3.7.304.21

Targeted .NET Platform

.NET 7

Operating System and version

Windows 10, Windows 11

@mihneavelinOT mihneavelinOT added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jun 4, 2024
@bhoradc
Copy link

bhoradc commented Jun 4, 2024

Hi @mihneavelinOT,

Thank you for reporting this issue. Can you confirm if your code follows the recommendations mentioned in this blog post, for handling UTC timestamp in SDK for .NET?

This Blog post mentions about practices to follow to prevent any potential timezone ambiguity in the code. This would ensure that the time value is treated consistently as UTC, regardless of the local execution environment.

Kindly share a code sample that I can use to reproduce this scenario, in case above recommendations doesn't work or won't apply to your use-case.

Thank you!

Regards,
Chaitanya

@bhoradc bhoradc added response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. p2 This is a standard priority issue and removed needs-triage This issue or PR still needs to be triaged. labels Jun 4, 2024
@bhoradc bhoradc self-assigned this Jun 4, 2024
@mihneavelinOT
Copy link
Author

Hi @bhoradc,

Thank you so much!!!

I will put my solution here, maybe it will help somebody else.

Before:
When inspecting TimestampUtc the date time seemed to be correct, but the DateTimeKind was wrong!!!
point.timestamp is a long storing the utc timestamp in seconds

TimestampUtc = DateTimeOffset.FromUnixTimeSeconds(point.timestamp).DateTime;

After:
Notice the explicit specification of the DateTimeKind.

var time = DateTimeOffset.FromUnixTimeSeconds(point.timestamp).DateTime;
TimestampUtc = DateTime.SpecifyKind(time, DateTimeKind.Utc);

@bhoradc
Copy link

bhoradc commented Jun 5, 2024

Hello @mihneavelinOT,

Glad to know that the blogpost helped. To help others who might be facing similar problems, I will move this Issue to the Discussions section. This way, others can find the solution and benefit from the conversation.

Regards,
Chaitanya

@bhoradc bhoradc converted this issue into discussion #3333 Jun 5, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
bug This issue is a bug. p2 This is a standard priority issue response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days.
Projects
None yet
Development

No branches or pull requests

2 participants