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

Year-only iso date string is parsed incorrectly #1247

Closed
kanongil opened this issue Jul 14, 2017 · 4 comments
Closed

Year-only iso date string is parsed incorrectly #1247

kanongil opened this issue Jul 14, 2017 · 4 comments
Assignees
Labels
breaking changes Change that can breaking existing code bug Bug or defect
Milestone

Comments

@kanongil
Copy link
Contributor

kanongil commented Jul 14, 2017

Context

  • node version: 8.1.4
  • joi version: 10.6.0
  • environment (node, browser): node
  • used with (hapi, standalone, ...): standalone
  • any other relevant information:

What are you trying to achieve or the steps to reproduce ?

Joi.date().iso().validate('2013').value.toISOString();

Which result you had ?

'1970-01-01T00:00:02.013Z'

What did you expect ?

Same output as new Date('2013').toISOString():

'2013-01-01T00:00:00.000Z'

As far as I can tell, it unexpectedly parses it as a timestamp value.

@DavidTPate
Copy link
Contributor

Yeah, that seems to be the case.

I think it is operating as expected, there's nothing there for it to use to determine whether the value is the number of milliseconds or a date. The closest thing to it is the the value happens to be a 4 digit number, but that would just be an assumption that it isn't a milliseconds value.

Did you have something in mind to address this? As I see it right now, I believe it is working as expected.

@nlindley
Copy link
Contributor

nlindley commented Oct 6, 2017

In the example, iso() is specified. Wouldn’t that imply the value isn’t intended to be milliseconds?

@Marsup Marsup added the bug Bug or defect label Aug 3, 2018
@Marsup Marsup self-assigned this Aug 3, 2018
@Marsup Marsup added the breaking changes Change that can breaking existing code label Aug 3, 2018
@Marsup Marsup added this to the 14.0.0 milestone Aug 3, 2018
@Marsup
Copy link
Collaborator

Marsup commented Aug 3, 2018

That's a good point @nlindley.

@lock
Copy link

lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking changes Change that can breaking existing code bug Bug or defect
Projects
None yet
Development

No branches or pull requests

4 participants