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