Missing conversions in `calendar`

[MarkoMin]

Is your feature request related to a problem? Please describe. The problem arises when you want to convert system time to datetime and vice versa. There are functions calendar:system_time_to_local_time/1 and calendar:system_time_to_local_time/1, but the inverse functions are missing (universal_time_to_system_time/1 and local_time_to_system_time/1).

Describe the solution you'd like I'd like those 2 functions introduced. Also, rfc3339_to_datetime/local_time/universal_time might be convenient, because currently you have to first transform it to system time and then to datetime/local/utc.

Describe alternatives you've considered Currently, I manually construct RFC3339 string from datetime and then call calendar:rfc3339_to_system_time/1, which is both hacky and inefficient.

Additional context These could be nicely property-tested: T = universal_time_to_system_time(system_time_to_universal_time(T)).

I'm willing to make a PR if anyone can confirm that those functions are suitable to be in calendar.

[paulo-ferraz-oliveira]

👍 the other day we were also looking at this. Lemme add we feel the following is also missing: conversion from Gregorian seconds to Unix time and back.

There's this magic number, 62167219200, that is mentioned at least 6 times in 5 different files of the current OTP code base, for example. On the other hand, maybe it's not been included because it was not deemed generic enough (?)

[MarkoMin]

LOL, so datetime->unixtime is significantly less generic than the other way around and only way to do this is to either datetime -> string -> unixtime or to reimplement logic from the conversion? The conversion is already implemented in rfc3339_to_system_time/1 and erlang:universaltime_to_posixtime/1 which is undocumented BIF and unfortunately returns in seconds...

EDIT: rfc3339_to_system_time/1 does the conversion by first parsing rfc3339 to datetime and then converts datetime to system time

[KunaPrime]

@MarkoMin i also want to point out magic OR mistake here:

• magic: issue #8160 dealing with time that is ISO 8601 standardized (same digits)
• mistake: you should have waited for 441 issues more, so that issue number would be the same as in ISO

[bjorng]

After the first release candidate, we generally focus on bug fixes and polishing of features already included or planned for the release. To ensure that Erlang/OTP 27 will be as good as it possibly can be, we need to minimize the time we spend on things not to be included in the release. Therefore, we will not investigate/consider this feature request until after OTP 27 has been released. If we have not came back to it before September, feel free to remind us.