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