timezone aware timestamps #3659
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The timestamp is localtime, so if output files are moved across time borders, they become less valuable then they could be. If this is important to someone, then add the ability to save a timezone and dst attribute in the status output of xml files. e.g. <status status="FAIL" starttime="20200909 12:38:31.781" endtime="20200909 12:38:31.788" timezone="10.0" dst="0"></status>
Use module variables to specify an 'override' for the timestamp into utc. User must change use_utc_timestamp module variable for utc to be used. Allowing for this as current timestamp is in local time, so use in databases may result in invalid date time search results if not set to same timezone.
Use module variables to specify an 'override' for the timestamp into utc and or iso8601 format. User must call default_to_iso8601() if they wish to use it, prior to doing an timestamp functionality. Borrow parsing routines from https://github.com/salabs/TestArchiver. Allowing for this as current timestamp is in local time without timezone informatoin, so it is unclear in output files when exactly the test was run.
To prepare for allowing iso8601utc option to be selected by the user add a commandline options or setting for it. Initially we will only allow iso8601utc as a value here, but theoretically this could become an arbitrary time format string in time. That would require a much larger rewrite of utils/robottime though.
…tions If the user specifies iso8601utc as the timestampformat update the robottime module by calling default_to_utc_timestamp() and default_to_iso8601() which will globally adjust the module to output timestamps in iso8601 utc with Z as suffix. e.g. 2020-09-10T06:59:11.436Z The intent is that in the future arbitrary formats could be specified.
Raising the base exception meant that higher level functions which were passing on ValueError failed incorrectly. Changing to throw a ValueError ensure alternate parse methods are used. e.g. on Get Time keyword, NOW is used and results in a normalised time of 'NOW00000 00:00:00.000', which results in an exception when parsing, hence acceptance and unit tests were failing.
The units tests test for a time format of "%Y%m%d %H:%M:%S:%f" so add it into the allowed time formats.
to be parsed to allow for adjusting timestamp options which effect logger also. Move location of the log to ensure the application log is first.
To avoid duplicate 'timestamp' prefixes for command line arguments modify the new argument slightly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To at least partly address timezone in timestamps as discussed in
#3061
and
https://groups.google.com/forum/#!topic/robotframework-users/Wtg8EYwNVJ8
proposing the addition of two options as detailed in usage.
-z --xoutputtimeinfo Include system timezone and daylight saving time in output.xml status elements so the timestamp are definitive.
--formattimestamp iso8601utc Provide a format for the timestamp. iso8601utc: Formatted as "%Y-%m-%dT%H:%M:%S.%fZ" e.g. 2020-09-10T06:17:37.831Z
The resultant output with both options is
<status> status="PASS" starttime="2020-09-10T07:37:25.717Z" endtime="2020-09-10T07:37:26.170Z" timezone="10.0" dst="0"></status>The more important of the two is the timestamp format, and the intent is that eventually the robottime module could evolve to allow arbitrary timestamp formats including ones with +/- timezones as per iso8601, e.g. 2020-09-10T07:52:07+10:00, at which point the other status attributes could be considered redundant.
I have not considered or tested side effects for rebot, but when run against a single output.xml file rebot resulted in html files with utc times.
e.g.
Status: All tests passed
Documentation: A suite of tests with tagged tests
Start Time: 20200910 07:54:24.615
End Time: 20200910 07:54:25.093
Elapsed Time: 00:00:00.478
Log File: log.html