-
Notifications
You must be signed in to change notification settings - Fork 94
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
DateTime elements have seconds precision, optimized for fractions #2308
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -24,7 +24,6 @@ | |
See the License for the specific language governing permissions and | ||
limitations under the License. | ||
""" | ||
import time | ||
import fs | ||
import pytest | ||
|
||
|
@@ -172,8 +171,6 @@ def test_get_all_changes(self): | |
with self.app.test_client(): | ||
flight_path, operation = self._create_operation(flight_path="V11") | ||
assert self.fm.save_file(operation.id, "content1", self.user) | ||
# we need to wait to get an updated created_at | ||
time.sleep(1) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Technically it would still need to wait a microsecond. Practically, I don't think that will ever be an issue... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. testing with sqlite would need a millisecond. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, microsecond is correct. As seen above the representation of DateTime in SQLite is stored with 6 decimal places, i.e. with a precision of one microsecond. |
||
assert self.fm.save_file(operation.id, "content2", self.user) | ||
all_changes = self.fm.get_all_changes(operation.id, self.user) | ||
# the newest change is on index 0, because it has a recent created_at time | ||
|
@@ -186,9 +183,7 @@ def test_get_change_content(self): | |
with self.app.test_client(): | ||
flight_path, operation = self._create_operation(flight_path="V12", content='initial') | ||
assert self.fm.save_file(operation.id, "content1", self.user) | ||
time.sleep(1) | ||
assert self.fm.save_file(operation.id, "content2", self.user) | ||
time.sleep(1) | ||
assert self.fm.save_file(operation.id, "content3", self.user) | ||
all_changes = self.fm.get_all_changes(operation.id, self.user) | ||
previous_change = self.fm.get_change_content(all_changes[2]["id"], self.user) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How flexible are we with this format? Is there some requirement on how it looks or is it just important that we use the same format for serialization and parsing between client and server respectively?
I am asking because I think this could just be
.isoformat
and.fromisoformat
respectively. See: https://docs.python.org/3/library/datetime.html#datetime.datetime.isoformat, https://docs.python.org/3/library/datetime.html#datetime.datetime.fromisoformat.With those there would be no potential for a format string mismatch and we would use a standardized representation that is unambiguous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to check with the timezone, isoformat would be prefered too.
a little headache I do have with the digits there, the testing setup needs 3 there. I have no idea, if the production system is happy or needs 6. This also the limitation here to milliseconds.
https://github.com/Open-MSS/MSS/pull/2308/files#diff-c721905a36cfba76833f0aa2f08229d63d2cbfa4ef0dcd2447a3e182880519b5R372
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Timezones shouldn't be an issue, they are properly handled by the isoformat methods. The number of zeros in that linked code line should be 6, since that would match what the %f format option also adds (6 zero-padded digits representing microseconds).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct
https://www.sqlite.org/lang_datefunc.html
In formats 4, 7, and 10, the fractional seconds value SS.SSS can have one or more digits following the decimal point. Exactly three digits are shown in the examples because only the first three digits are significant to the result, but the input string can have fewer or more than three digits and the date/time functions will still operate correctly. Similarly, format 12 is shown with 10 significant digits, but the date/time functions will really accept as many or as few digits as are necessary to represent the Julian day number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't follow. What are formats 4, 7, 10 and 12? Are you quoting from somewhere without referencing the source?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was because on many places the fractions symbolized by 3S
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, OK, this applies to the date and time related functions from SQLite. I don't think SQLAlchemy uses those though (it just dumps iso 8601 formatted strings to the database and reads those back as strings before parsing them, SQLite only ever sees text and doesn't have to parse it), so I don't think any of that applies to our use here.