-
Notifications
You must be signed in to change notification settings - Fork 88
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
Allow different date formats #146
Comments
I would favor the current behavior for Day and Timestamp remaining the default unless a major version jump is made--making them match against now-invalid formats could break downstream consumers expecting only the currently-valid format. An "any" option seems like an iffy/moving target, given just how many date formats there are out there (assuming Yamale doesn't stop at the first N proposed or set out to include nearly every format out there), e.g. Wikipedia: Date format by country. How about a |
I think using the strptime format is a good idea. The default for this could be left as is so it doesn't break any current workloads. I can investigate what this would require on the code side. I need this functionality for a current project and am happy to share if others would find it useful. |
Hi! Thanks for using Yamale! Currently, pyyaml will deserialize ISO8601 date formats into python datetime.date or datetime.datetime objects. Yamale takes advantage of this behavior for validating the min/max constraints...and for validity. That should remain the default as @mechie suggested. I also agree with the suggestion of a If updating the validator gets to be too much, you can fall back on regex validators if you don't need the min/max constraints. |
Hi guys, I dug into this over the weekend and have a workable but somewhat inelegant solution. I wanted to run it past you for a gut check before proceeding. I can create a new constraint called My proposal is to update Thoughts? |
The way it's described, that sounds a-ok to me, specially since the relative inefficiency is opt-in through the constraint. I'm not a maintainer, though. How do the Date/Timestamp min/max constraints account for this change? Are they going to be subclassed and passed Separate (but related) doubt, should all constraints on a Date/Timestamp follow DateFormat's tune? i.e., if I pass a DD-MM-YY format in to a Date, should I expect to be able to (or must?) format my min/max constraints that way? |
Another way to handle this would be to override the For the constraints, I would think using the same format for Thanks for taking this on! |
Happy to help! I'm still working on this but have run into an issue. Any suggestions would be appreciated. I took @mildebrandt's advice to override the I'm not sure if there's a way we can easily look up the format of the data in the original file without a lot of extra work. Alternatively the default resolver for date/datetime in PyYAML could be overwritten by creating a custom class to extend Is there a better way to do this? |
That is a sticky issue. I haven't verified this, but it seems that the try: # Try to convert value
# Is this value one of the datetime types?
if kwtype == datetime.date:
time = datetime.datetime.strptime(value, '%Y-%m-%d')
return datetime.date(time.year, time.month, time.day)
if kwtype == datetime.datetime:
return datetime.datetime.strptime(value, '%Y-%m-%d %H:%M:%S')
return kwtype(value)
except (TypeError, ValueError):
raise SyntaxError('%s is not a %s' % (key, kwtype)) |
I'm not sure I follow. The issue I'm seeing is on the data side, not on the constraint side. Let's say we have a data.yaml file as follows:
When we call
PyYAML is parsing anything that matches a specific regex as a date, we lose the original formatting of the date so there is no way (that I can figure out) to compare the original format of the date to the format passed to the Day validator. I'll have to research it more, but one workaround would be if the PyYAML parser only converts strings if they match the YYYY-MM-DD format. If so, we can check that the format argument is I still need to investigate if this issue shows up if using rumel as the loader. |
Ah, I misunderstood....though I think you'll still have the issue I mentioned when you start testing constraints. For this, we could tell the parser to not convert dates and timestamps. However, we have to be VERY careful that we do EXACTLY what PyYAML and ruamel do when parsing dates and times when a Here are a couple examples: |
I created a pull request for this feature. I was able to mimic the default PyYAML and ruamel behavior in a function called I wrote and ran several tests which all passed. Please take a look and let me know if there is anything that I missed! |
Sorry it's taking a long time to get to this, we're pretty busy over here. Hopefully I can schedule some time soon. |
No worries, I totally get it! |
I'd like to modify the Day validator to allow for other date formats: MM/DD/YYYY, MM-DD-YYYY, DD-MM-YYYY, etc. The user could specify a specific format or omit the argument to allow for matching against any of the approved formats (allowing for more flexibility in the data).
I'm happy to build the solution if you think this is useful.
The text was updated successfully, but these errors were encountered: