Fix it so that SysTime's from*String supports more than 7 digits.#5389
Merged
dlang-bot merged 1 commit intodlang:masterfrom May 17, 2017
Merged
Fix it so that SysTime's from*String supports more than 7 digits.#5389dlang-bot merged 1 commit intodlang:masterfrom
dlang-bot merged 1 commit intodlang:masterfrom
Conversation
CyberShadow
approved these changes
May 13, 2017
…7 digits. ISO 8601 says that it's up to the application to decide how many digits to put in the fractional seconds if they're present. SysTime.to*String puts up to 7 (stripping trailing zeroes), because that's hecto-nanosecond precision, and SysTime holds the time in hecto-nanoseconds. Currently, from*String only accepts up to 7 digits in the fractional seconds, which _does_ follow the spec in that (per the spec) the number of digits is up to the applications. However, while we never emit more than 7 digits, other applications do, so only accepting 7 digits makes us incompatible with them, whereas accepting them would make us more compatible with other programs, and it would actually be more efficient, since we'd have fewer checks in the code. So, these changes make is so that SysTime.from*String accepts more than 7 digits in the fractional seconds, but the additional digits are truncated (since SysTime doesn't support more than 7 digits of precision).
Contributor
|
wilzbach
approved these changes
May 14, 2017
Contributor
wilzbach
left a comment
wilzbach
left a comment
There was a problem hiding this comment.
LGTM as well - it seems we still have the issues with the Project Tester. @CyberShadow could you disable it from the required CIs as long as Martin isn't reachable, s.t. PRs aren't unnecessarily blocked?
Member
Done |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
ISO 8601 says that it's up to the application to decide how many digits
to put in the fractional seconds if they're present.
SysTime.to*Stringputs up to 7 (stripping trailing zeroes), because that's
hecto-nanosecond precision, and
SysTimeholds the time inhecto-nanoseconds. Currently,
from*Stringonly accepts up to 7 digits inthe fractional seconds, which does follow the spec in that (per the
spec) the number of digits is up to the applications. However, while we
never emit more than 7 digits, other applications do, so only accepting
7 digits makes us incompatible with them, whereas accepting them would
make us more compatible with other programs, and it would actually be
more efficient, since we'd have fewer checks in the code.
So, these changes make is so that
SysTime.from*Stringaccepts more than 7digits in the fractional seconds, but the additional digits are
truncated (since
SysTimedoesn't support more than 7 digits ofprecision).