Well, the spirit of "cast" is to provide conversions where there is only "one way to do it" (subject to certain nuisances like decimal point / comma distinction based on locale). Since there are many possible ways to display a temporal type as a string, I'm not sure this qualifies, instead it seems preferable then to force the use of a strftime-like function to indicate how you wish for a timestamp to be converted to a string (or timestamp_to_iso8601 would be a fast iso8601 formatter)
On Tue, Jul 14, 2020 at 1:47 PM Antoine Pitrou <anto...@python.org> wrote: > > > But is there a point in forcing a different function name (except > annoying the poor developer)? > > > Le 14/07/2020 à 20:22, Wes McKinney a écrit : > > I would actually be OK with disallowing temporal -> string inside > > Cast. SQL systems only provide this through functions like TO_CHAR > > > > https://www.postgresql.org/docs/12/functions-formatting.html > > > > On Tue, Jul 14, 2020 at 1:18 PM Antoine Pitrou <anto...@python.org> wrote: > >> > >> > >> I suppose "cast" to string is just another way of saying "represent as > >> string". We may want a specific name for T -> string and string -> T. > >> Feel free to discuss :-) > >> > >> As for mandating a format, though, that's a bit annoying in the common > >> case. It's ok to be able to customize the representation format, but > >> there should be a convenient default case that doesn't need any > >> parametering. > >> > >> Regards > >> > >> Antoine. > >> > >> > >> Le 14/07/2020 à 20:12, Neal Richardson a écrit : > >>> Are we sure that "casting" should be supported? date/timestamp -> string > >>> sounds to me like "format" with parameters (like strftime tokens, which > >>> may > >>> default to ISO-8601), not "cast". Likewise, string to timestamp sounds > >>> like > >>> "parse" (also with parameters), not "cast". > >>> > >>> Neal > >>> > >>> > >>> On Tue, Jul 14, 2020 at 10:55 AM Wes McKinney <wesmck...@gmail.com> wrote: > >>> > >>>> I agree with using ISO 8601 or the constituent components (date or time) > >>>> thereof > >>>> > >>>> On Tue, Jul 14, 2020 at 12:48 PM Antoine Pitrou <anto...@python.org> > >>>> wrote: > >>>>> > >>>>> > >>>>> Le 14/07/2020 à 19:40, Ben Kietzman a écrit : > >>>>>> string -> date32 is not implemented, AFAICT. > >>>>>> > >>>>>> I agree that a timestamp seems ideal, that way string -> date32 should > >>>>>> produce the same result as string -> timestamp -> date32. > >>>>>> > >>>>>> A related question: what format would be expected for time32<seconds> > >>>> <-> > >>>>>> string? > >>>>> > >>>>> "HH:MM:SS" perhaps? > >>>> > >>>
