question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

ToString on Empty Period does not follow ISO8601 returns 'P'

See original GitHub issue

When doing ToString on a zero period (happen on both lines in the unittest below), I get 'P' as the result. This is not valid ISO8601, as this requires a zero period to have at least a single field given, such as 'P0S', of 'P0D'. This also seems to contradict the behavior described in ticket #46.

        [Test]
        public void DurationToString()
        {
            Assert.AreEqual("P0S", Period.FromSeconds(0).ToString(), "Period 0 seconds"); // Actually is 'P'
            Assert.AreEqual("P0S", Period.Zero.ToString(), "Period without fields"); // Actually is 'P'
        }

Note that we run into empty Periods when storing a 0 period in our postgresql database, and retrieve it using the NodaTime type mapping in entity framework these periods then get serialized to JSON using NodaTime.Serialization.SystemTextJson.

Tested using nodatime 3.0.5

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
jskeetcommented, Apr 28, 2021

Good catch - thanks. It should be fairly easy to fix… I’ve been thinking of creating a 3.1.0 release anyway, so it could go into that. I do wonder whether it’s worth backporting to 3.0.x and 2.4.x though…

0reactions
jskeetcommented, May 1, 2021

Looking into this, it seems the “normalising ISO” pattern already uses “P0D”. It’s only the round-trip pattern (which is used by Period.ToString) that fails. The use of “P0D” is unfortunate as after considering it a bit, I think I’d prefer “P0S” as well, but I don’t want to change behaviour of any already-working code. I’ll make both use “P0D” for now, and consider making it configurable in the future.

For backward compatibility, I think I probably need to make the normalising pattern accept just “P” - otherwise anyone trying to parse a value they’ve previously formatted will run into problems. It’s one of those situations where there’s no good solution, unfortunately… but I’ll do what I can.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Java convert ISO 8601 string to Date ignoring offset
I have a string coming to me in the following format "yyyy-MM-dd'T'HH:mm:ssZ" ex: 2020-09-09T09:58:00+0000" offset is UTC. ... As you can see ...
Read more >
Convert DateTime to ISO 8601 String in C# - Code Maze
In this article, we are going to learn how to convert DateTime to ISO 8601 string in C#. There are various formats of...
Read more >
java.time.Duration.toString() Method Example
The java.time.Duration.toString() method gets a string representation of this duration using ISO-8601 seconds based representation, such as PT8H6M12.345S.
Read more >
DateTime and DateTimeOffset support in System.Text.Json
The System.Text.Json library parses and writes DateTime and DateTimeOffset values according to the ISO 8601-1:2019 extended profile.
Read more >
Temporal.Duration
Briefly, the ISO 8601 notation consists of a P character, followed by years, months, weeks, and days, followed by a T character, followed...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found