-
-
Notifications
You must be signed in to change notification settings - Fork 491
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
Add DateTimeConverter #234
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this. I added a few comments. Can you take a look at them?
/// </summary> | ||
public class DateTimeConverter : IYamlTypeConverter | ||
{ | ||
private readonly DateTimeKind _kind; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't prefix members with underscores in this project. Please remove them to ensure consistency with the codebase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I overlooked that convention. Sorry about that. I'll remove those underscore prefixes.
var value = ((Scalar)parser.Current).Value; | ||
var style = this._kind == DateTimeKind.Local ? DateTimeStyles.AssumeLocal : DateTimeStyles.AssumeUniversal; | ||
|
||
var dt = DateTime.ParseExact(value, this._formats, CultureInfo.InvariantCulture, style); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we allow to specify the culture that is to be used for reading and writing? What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also thought about that and concluded to keep invariant culture as I thought it should not be culture-specific.
However, as soon as I read your comment, an idea popped up on top of my head. I'll update the DateTimeConverter
class to pass CultureInfo
value to handle specific culture, like DateTimeKind
value. But I'd still like to keep CultureInfo.InvariantCulture
as its default value, if no CultureInfo
value is provided. How does it sound to you?
- Added IFormatProvider to specify culture - Updated private fields not using prefixes to meet coding conventions
@aaubry As requested, I've made some changes. |
@aaubry Could you run the build at AppVeyor again? It should pass all tests as I ran the test same way as what the build process did. I used |
@aaubry FYI, I've run this build against my forked branch on AppVeyor and confirm the build passed the test. For some reason, the build process was interrupted at that time. https://ci.appveyor.com/project/justinyoo/yamldotnet/build/4.0.1-pre1 Could you run the build, https://ci.appveyor.com/project/aaubry/yamldotnet/build/4.0.1-pre314, again at your end, please? |
I was unable to reply sooner, sorry. I ran the tests locally and the test fails occasionally. But if I run the tests again, they pass. I'm not really sure what's going on, but I'll investigate further. |
I have updated FakeItEasy to version 2.3.3 and now it seems that the tests always pass. |
Hi, @justinyoo, I noticed recently, while working on #255, that some of the DateTime tests fail on Linux with Mono. I had to comment out some of them, apparently the ones that use the Korean AM/PM designator. I thought that maybe you knew of a workaround? Thanks |
@aaubry ORLY? Yeah, for now you can comment that out. Seems that tests only fail where AM/PM designator exists. I'll have a look. |
As discussed in #231 , I'd like to send this PR for
DateTimeConverter
. It would be great if you have a review and merge it.What it does are:
DateTimeKind.Utc
and Standard Date and Time Format Strings of "G" as its default parameters, if they are omitted.FormatException
. Please refer to my whole test cases.Here are examples of usage:
Please note: According to Standard Date and Time Format Strings, there's no difference between "F" and "U", in terms of string representation. Therefore, if both are provided into the converter at the same time, it will return unexpected result.