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

partial seconds returns 0 value #27

Open
mlevkov opened this issue Mar 24, 2020 · 4 comments
Open

partial seconds returns 0 value #27

mlevkov opened this issue Mar 24, 2020 · 4 comments

Comments

@mlevkov
Copy link

mlevkov commented Mar 24, 2020

Hello,

I've encountered the scenario where duration format for seconds is presented as follows

"PT1420.061S" which would correspond to seconds and fractional seconds (ms). It appears that when I pass this value to your library, I'm getting a 0 value across all fields, which I would assume is the default.

{
    year: 0,
    month: 0,
    day: 0,
    hour: 0,
    minute: 0,
    second: 0,
    millisecond: 0,
}

Is there is something I need to do here?

Thank you

@hoodie
Copy link
Collaborator

hoodie commented Mar 24, 2020

I don't really recognized the 'PT' you use here. How can you reproduce this? I tried something like this:

#[test]
fn issue_27() {
    assert_eq!(
        time("1420.061S"),
        Ok(
            Time {
                hour: 14,
                minute: 20,
                second: 0,
                millisecond: 61,
                tz_offset_hours: 0,
                tz_offset_minutes: 0,
            },
        )
    );
}

@mlevkov
Copy link
Author

mlevkov commented Mar 27, 2020

Ok, thank you. Will take a look and let you know.

@mlevkov
Copy link
Author

mlevkov commented Mar 27, 2020

@hoodie I've looked further into this after looking through the XMLSchema.xsd and this specific type designation as described here: https://www.w3.org/TR/xmlschema-2/#duration. What appears to be the case is that T in the PT1420.06S is a Time designation when date is not present (absent). Effectively, it would read like this PT1420.06S is represented in short as PT1420.06S. So, instead of writing P0Y0M0DT1420.061S, one would write like this PT1420.061S in short.

@mlevkov
Copy link
Author

mlevkov commented Apr 20, 2020

@hoodie I was looking through your tests and noticed that issue that I've noted above is the same one described in your test here: https://github.com/badboy/iso8601/blob/master/tests/lib.rs#L1057, I'm not correct?

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