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
Relax UTCTime format string #201
Closed
Closed
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
This is consistent with the aeson encode en decode. This does not change the benchmark results.
This lets us see the cost of string encoding more clearly.
This improves performance by about 10%.
This is necessary due to the backwards incompatibility introduced in the fix for haskellgh-53.
Nullary constructors are encoded as an empty array. The syb code wrongfully assumed they were encoded as Null.
Proposed fix for haskell#177. This does have the downside that it would immediately require text-1.1, which might cause for some people committed to older versions of the Haskell Platform.
This allows us to work with the version of the Haskell Platform that is current as of early 2014.
Data instance for HashMap, which only seems to appear in 0.2.3.0, but aeson's current dependency is only on 0.1.3.0. Data instance for HashMap
depends on unordered-containers 0.2.3.0 for HashMap Data instance
Pred now is just an alias of Type. See GHC Trac #7021.
This means that dependency solver's job is easier (it doesn't need to consider the opposite flag setting) and it means that cabal cannot automatically switch these flags (which I don't think happened in the past, but it's theoretically possible).
The old rational parser applied realToFrac (fromRational . toRational) to the Scientific number to construct a new Scientific number. This had the disadvantage that scientific numbers with big exponents like 1e1000000000 are converted from (Scientific 1 1000000000) to (Scientific (1*10^1000000000) 0). If the Integer coefficient of the latter is later evaluated it will allocate all memory. This is the first step needed to fix haskell#198.
Integral types can now be parsed safely (bounded space usage). Parsing fractional types (Float and Double) still allows an attacker to fill up the memory of the target system by supplying a number with a large exponent. Fixing this is on my TODO list.
--HG-- branch : hashmap extra : close : 1
It's quite common to encounter timestamp strings of format: 2014-04-28 13:13:13.112233 2014-04-28 13:13:13 (I.e., without 'T' in the middle and without the 'Z' postfix) An example source of these strings is SQLite: sqlite> select datetime('now'); 2014-04-28 12:35:12 Rather than fail to parse these strings, allow them in JSON -> UTCTime conversion. See haskell#197 for more examples & test case that reproduces the failure.
I'm -1 on not requiring the TZ indicator as explained in #197 (comment) |
What about accepting UTC offsets? I use offsets instead of Z in all my log files. |
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.
It's quite common to encounter timestamp strings of format:
2014-04-28 13:13:13.112233
2014-04-28 13:13:13
(I.e., without 'T' in the middle and without the 'Z' postfix)
An example source of these strings is SQLite:
sqlite> select datetime('now');
2014-04-28 12:35:12
Rather than fail to parse these strings, allow them in JSON -> UTCTime
conversion.
See #197 for more examples & test case that reproduces the failure.