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

Relax UTCTime format string #201

Closed
wants to merge 564 commits into from
Closed

Conversation

nurpax
Copy link
Contributor

@nurpax nurpax commented May 8, 2014

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.

bos and others added 30 commits November 30, 2011 21:45
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.
lpsmith and others added 26 commits January 10, 2014 19:06
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.
@hvr
Copy link
Member

hvr commented May 25, 2014

I'm -1 on not requiring the TZ indicator as explained in #197 (comment)

@blancas
Copy link

blancas commented Jul 14, 2014

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet