Should maximum/minimum have the same fmt/pattern?
See original GitHub issueI suppose it’s correct:
type: date
format: fmt:%Y
constraints:
minimum: 2015
And it’s not correct:
type: date
format: fmt:%Y
constraints:
minimum: 2015-12-12 # bad format
Should be clarified in spec (which one is correct).
For implementations the same format for both is much more preferable way (because minimum/maximum could be cast using the same approach as value). And for now python version acts based on snippet #1 workflow.
Issue Analytics
- State:
- Created 7 years ago
- Comments:18 (18 by maintainers)
Top Results From Across the Web
Support "missing" values · Issue #97 · frictionlessdata/specs
Fields should have a way how to specify the missing values, if relevant. It is go... ... Should maximum/minimum have the same fmt/pattern?...
Read more >Local and Absolute Maximum and Minimum from a Graph
In this video, we are given a graph and have to determine the relative (local) maximum and minimums as well as the absolute...
Read more >Calculus: Maximum-Minimum Problems With Two Variables
This video discusses how to find maximum and minimum values of a function of two variables using the second derivative test ("D-test").
Read more >Absolute & Local Minimum and Maximum Values - YouTube
This calculus video tutorial explains how to find the absolute minimum and maximum values as well as the local max and local min....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@roll could you please help me out here, and go through the list of constraints, and not here what is before/after (just to ensure I don’t miss any concerns from implementation perspective). I will then update specs accordingly.
@rgrp @roll @akariv @frictionlessdata/specs-working-group
I think we should be explicit about constraints applying to the value before parsing. Implementing code could handle the cases where it is dealing with an already cast value or not.
So, constraints like
enum
should be arrays of strings, each parsable as the type/format of the field.