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

Date.date #7

Closed
retorquere opened this issue Oct 26, 2016 · 4 comments
Closed

Date.date #7

retorquere opened this issue Oct 26, 2016 · 4 comments

Comments

@retorquere
Copy link

I'm trying to get the day-of-month value from a parsed date, but I'm getting some things I didn't expect:

edtf('2016-07-18T20:26:06+10:00').date = 19
edtf('-0876').date = 1

I sort of get the first, but I'd still prefer to have a way to get 18 out. The 2nd, I had expected undefined rather than 1.

@inukshuk
Copy link
Owner

inukshuk commented Oct 26, 2016

Regarding the first example: we are always converting to UTC, because otherwise a number of important calculations would become insanely difficult or simply impossible. The date is still correct, so you can calculate it according to your desired timezone. If you are just interested in the string representation (i.e., get 18 out) then don't use the date library, just parse the string:

e.parse('2016-07-18T20:26:06+10:00').values[2]
// -> 18

Similarly for the second example, don't use the date library if you just want to parse the numbers:

e.parse('-0876').values[2]
// -> undefined

The point of the date library is to manipulate dates and convert them back to EDTF strings. For that reason, we're using the concept that every extended date covers a period of time with a min/max value. This approach is necessary to do computations, that's why the day exists, even though the date has year precision (you can still query the precision and convert the date back to a string and you will see that there is no day set, but because it is required for computations you can still get an approximation if you need it).

@retorquere
Copy link
Author

Please do let me know if this is not the proper channel... if I parse 1999-XX-XX I get (as expected) { values: [ 1999, 0, 1 ], unspecified: 240, type: 'Date', level: 1 }, but .unspecified.is(...) clearly won't work here. How do I call Bitmask directly to find out what part is unspecified?

@retorquere
Copy link
Author

Or could I just use edtf('...').values and edtf('...').unspecified.is(...)?

@inukshuk
Copy link
Owner

Yes, you can either use the extended date objects directly, or, alternatively, use the Bitmask class (unspecified and uncertain are simply Bitmask instances created from the numeric value returned by the parser).

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

No branches or pull requests

2 participants