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? >>>> >>>
