In a SQL context, "cast" to/from date times is converted if the string matches the literal format matches. E.g. BQ standard SQL [1]. But naming is hard :)
[1] https://cloud.google.com/bigquery/docs/reference/standard-sql/conversion_rules#casting_date_types On Tue, Jul 14, 2020 at 1:09 PM Wes McKinney <wesmck...@gmail.com> wrote: > 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? > > >>>> > > >>> >
