For whatever it's worth, it seems to me that if you're using ISO8601 as the canonical representation of time in your application (whether for the user-facing representation, or for database-facing representation), it means that you're already okay with losing this locale information.
Maybe it's a lack of imagination on my part, but it's hard for me to imagine a real-world application where the ISO8601 format is used to represent time but the locale/daylight-savings-time information is important - I'd think that if this information was important to you, you wouldn't use a machine-oriented format that throws the information away. That is, for human facing display formats we throw information like this away quite often (e.g. human-friendly sentence formats like "5 days ago"), but ISO8601 is a mostly machine-friendly format (that happens to be somewhat human-friendly), so it seems unlikely to be part of an application unless it encodes everything the application needs. To think about it in another way, you lose the information when you do `DateTime.to_iso8601`, not in `DateTime.from_iso8601`. If anything, it seems like `DateTime.to_iso8601` should be the controversial, disclaimered transformation because this is the lossy point where information about the specific locale is lost. I definitely agree that we want to prioritize correctness and avoid surprising behaviour, but I think this tradeoff (applications that store/accept/parse data in a lossy format can't make use of the lost information) is pretty reasonable and would do a good job of making the standard library maximally useful for the widest variety of applications, provided that the caveats/limitations are well-documented. Particularly in this specific case, it seems to be a common tradeoff made with respect to ISO8601-parsing libraries (see the `timex` library and Ruby standard library examples I quoted in the previous email). Also, I recognize that I can simply use `timex` for my application and be done with it, as it already behaves exactly like I'm talking about, but 1) I think this would be a reasonable and congruent thing to expect from the standard library, and 2) the `timex` application does a ton of things that I don't need it to, and even requires to be added to the mix `applications` so it can run supervised backend processes - definitely more than I expect for just wanting to parse a string to a DateTime. Thanks for your consideration! On Mon, Nov 28, 2016 at 10:15 AM, José Valim <[email protected]> wrote: > You have quoted the rationale correctly: ISO8601 does include the proper > timezone. > > I will have to discuss with maintainers what is the best way to go from > here. Using "Etc/GMT+3" may potentially defeat the purpose of using DateTime > because we will be unable to properly account for time changes. On the other > hand, we may add the proposed function with extensive disclaimers about its > behaviour. > > José Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/WbvuNovvB0U/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B3F0U03svEfAy85_qscW3Ay6Eb2YLx4UqGNAbyYNTaVQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- 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/CAPGBM9b3ZZ7SuMN07dXt_HRZ%3Dxc3kRZcfMBQKzZ03M5M81L64Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
