[Proposal] Improved handling of offset in ISO8601 strings.

[ma...@jonrowe.co.uk]

Hello!

I'm dealing with ISO8601 strings for date times, and the current libraries make my use case, which is dealing with clock time but preserving the offset from UTC, very frustrating.

Specifically (unless I'm mistaken) there is no inbuilt functions that allow reversible parsing of them.

e.g.

Given "2020-09-7T10:59:00+0100" I can parse this into a UTC DateTime and an offset, or a NaiveDateTime ignoring the offset, but from either of these I cannot reproduce "2020-09-7T10:59:00+0100".

I understand that an offset is not a timezone, so I understand why by default it does get converted to UTC, but it does represent the clock time at a point in time (which is useful for historical time series data like I'm working with).

What I propose is two options:

1) Have either/both DateTime and/or NaiveDateTime's `to_iso8601/2` expanded to take an offset back for the point of formatting, e.g.

```

{:ok, utc_dt, offset} = DateTime.from_iso8601("2020-09-7T10:59:00+0100")

"2020-09-7T10:59:00+01:00" = DateTime.to_iso8601(utc_dt, :extended, offset)

```

2) Have NaiveDateTime capture offset into it's struct, and allow it to be included when formatting date times.

```

{:ok, naive_dt} = NaiveDateTime.from_iso8601("2020-09-7T10:59:00+0100")

"2020-09-7T10:59:00+01:00" = NaiveDateTime.to_iso8601(naive_dt, :extended_offset)

```

I'd be happy to work on either / both of these, but currently I have to use DateTime.add and manually edit the struct to get the result I want, and given that the inbuilt libraries are more than sufficient for all my other purposes the current iso8601 handling feels like it could be improved

Cheers and look forward to feedback

Jon

[Arthur Collé]

Elixir datetime is such a mess. Even python is better and that's saying a lot.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/04e5e287-7a5b-45f1-a56c-54137bd14a23n%40googlegroups.com.

[José Valim]

Hi Jon,

Thanks for the proposal. Question: could you work with the datetime in UTC, keeping its offset on the side, and then include the offset only when formatting it? The question is: is this purely a parsing/formatting concern?

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAHsqzVEpdVGbvV49vVZt7bhoNvjT-%2BK%3DNnMQ%2BowmJt_A%3DqL0Uw%40mail.gmail.com.

[José Valim]

Hi Arthur,

If Elixir datetime is a mess, please contribute to the discussion showing use cases where you can't achieve the desired result or where the current API is confusing. Jon has just provided a great example of how to contribute, where he illustrated the problem and proposed solutions, and it is a bit unfortunate that the immediate follow up to his post is precisely the opposite.

If you can't contribute to the discussion, please abstain from posting. Thank you.

On Mon, Sep 7, 2020 at 12:14 PM Arthur Collé <arthu...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAHsqzVEpdVGbvV49vVZt7bhoNvjT-%2BK%3DNnMQ%2BowmJt_A%3DqL0Uw%40mail.gmail.com.

[ma...@jonrowe.co.uk]

Hi José

Yes I could, my primary need is to provide the offset in the ISO8601 string in the absence of other information. It would be more convenient, and in my opinion, more complete, to have NaiveDateTime capable of storing the offset, as it makes it easier to encapsulate the information without losing it, but if that produces undesired complexity for others its not a necessity for my needs.

Cheers

Jon

[José Valim]

Thanks Jon! We will be glad to accept a pull request for your proposal 1. It makes sense too: if DateTime returns the offset on from_iso, we should probably accept it on to_iso.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/dc591c74-01a7-4387-b9b5-8b69e81e3719n%40googlegroups.com.