jorisvandenbossche commented on pull request #10610: URL: https://github.com/apache/arrow/pull/10610#issuecomment-901843106
We still have the naming issue (or bikeshedding) to resolve. As a reference, some names used by other systems that I am aware of: * Pandas: [tz_localize](https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DatetimeIndex.tz_localize.html) * R's lubridate: [force_tz](https://lubridate.tidyverse.org/reference/force_tz.html) * Java: [atZone](https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#atZone-java.time.ZoneId-) * Java Joda: [toDateTime](https://www.joda.org/joda-time/apidocs/org/joda/time/LocalDateTime.html#toDateTime-org.joda.time.DateTimeZone-) * Postgresql: [AT TIME ZONE](https://www.postgresql.org/docs/13/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT) The proposals that have been floated around above: * `tz_localize` * `force_tz` * `local_datetime_to_zoned_datetime` I left out `tz_normalize` (like Weston mentioned, "normalize" already has too many meanings, it also doesn't give any indication to me whether it's adding or removing a timezone ..). I personally like Adam's suggestion of being more explicit (although resulting in a longer name) and re-using the terminology that was now added to the format spec to clarify the meaning. I would maybe only use "timestamp" instead of "datetime", since the actual types in arrow that this kernel accepts are called that way. With that, I would do a proposal of calling it `timestamp_local_to_zoned` ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
