Skip to content
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

fix(hardware-testing): fix ABR asair sensor time adjustment #15658

Merged
merged 5 commits into from
Jul 17, 2024

Conversation

rclarke0
Copy link
Contributor

Overview

Change asair time adjustment from 5 hrs to 4 hrs to account for daylight savings.

Test Plan

Changelog

Review requests

Risk assessment

@rclarke0 rclarke0 requested a review from a team as a code owner July 15, 2024 17:54
@rclarke0 rclarke0 requested review from a team and sfoster1 July 15, 2024 17:54
Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooh, let's not do this this way (unless you like having this exact same PR twice a year). Instead, either:

  • If this code runs on a robot, move adjusting the timestamp to someplace that is not on a robot; this possibly includes "google sheets", making it known in the data that the time is in UTC and doing something gross like this: https://davidkeen.com/blog/2017/01/time-zone-conversion-in-google-sheets/ because google doesn't do timezone conversion for some reason (?)
  • If this code runs on a laptop, which would indeed be happy and is what it looks like, then instead of doing timestamp = datetime.datetime.now() you can do timestamp = datetime.datetime.now(tz=tzinfo.utcoffset(0)) (tzinfo.utcoffset will generate the appropriate time zone info for the conversion), which also will work even if you run this script with a locale and timezone set to somewhere other than new york for whatever reason.

@rclarke0 rclarke0 requested a review from sfoster1 July 16, 2024 12:18
@rclarke0 rclarke0 requested a review from a team July 17, 2024 13:41
Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@rclarke0 rclarke0 merged commit c25c96d into edge Jul 17, 2024
7 checks passed
@rclarke0 rclarke0 deleted the fix-time-adjustment branch July 17, 2024 18:51
SyntaxColoring pushed a commit that referenced this pull request Jul 17, 2024
<!--
Thanks for taking the time to open a pull request! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

Change asair time adjustment from 5 hrs to 4 hrs to account for daylight
savings.

# Test Plan

<!--
Use this section to describe the steps that you took to test your Pull
Request.
If you did not perform any testing provide justification why.

OT-3 Developers: You should default to testing on actual physical
hardware.
Once again, if you did not perform testing against hardware, justify
why.

Note: It can be helpful to write a test plan before doing development

Example Test Plan (HTTP API Change)

- Verified that new optional argument `dance-party` causes the robot to
flash its lights, move the pipettes,
then home.
- Verified that when you omit the `dance-party` option the robot homes
normally
- Added protocol that uses `dance-party` argument to G-Code Testing
Suite
- Ran protocol that did not use `dance-party` argument and everything
was successful
- Added unit tests to validate that changes to pydantic model are
correct

-->

# Changelog

<!--
List out the changes to the code in this PR. Please try your best to
categorize your changes and describe what has changed and why.

Example changelog:
- Fixed app crash when trying to calibrate an illegal pipette
- Added state to API to track pipette usage
- Updated API docs to mention only two pipettes are supported

IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED
-->

# Review requests

<!--
Describe any requests for your reviewers here.
-->

# Risk assessment

<!--
Carefully go over your pull request and look at the other parts of the
codebase it may affect. Look for the possibility, even if you think it's
small, that your change may affect some other part of the system - for
instance, changing return tip behavior in protocol may also change the
behavior of labware calibration.

Identify the other parts of the system your codebase may affect, so that
in addition to your own review and testing, other people who may not
have the system internalized as much as you can focus their attention
and testing there.
-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants