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?
On Mon, Sep 7, 2020 at 12:14 PM Arthur Collé <[email protected]> wrote: > Elixir datetime is such a mess. Even python is better and that's saying a > lot. > > On Mon, Sep 7, 2020 at 6:12 AM [email protected] <[email protected]> > wrote: > >> 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 >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/04e5e287-7a5b-45f1-a56c-54137bd14a23n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/04e5e287-7a5b-45f1-a56c-54137bd14a23n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 [email protected]. > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/CAHsqzVEpdVGbvV49vVZt7bhoNvjT-%2BK%3DNnMQ%2BowmJt_A%3DqL0Uw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BwCqYSmU%2Becz0b9tEMS5z_EmHif40d8sfwfvLFQrU6Cg%40mail.gmail.com.
