Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ostream insert local_time on Visual Studio 2022 with C++20 #773

Open
tonygould opened this issue Jan 27, 2023 · 4 comments
Open

Ostream insert local_time on Visual Studio 2022 with C++20 #773

tonygould opened this issue Jan 27, 2023 · 4 comments

Comments

@tonygould
Copy link

There is a compile failure on Visual Studio 2022 with C++20. Repro

    constexpr date::local_time<date::days> d{date::year{2015} / date::March / 22};
    std::ostringstream& os;
    os << d;

leads to

error C2593: 'operator <<' is ambiguous
date.h(4221): could be 'std::basic_ostream<...> &date::operator <<...
or       'std::basic_ostream<...> &std::chrono::operator <<...

I have a fix (on a local branch but I can't seem to create remote branch). Would be good to incorporate this. I'd like to have the exact same date/timezone code on both windows and linux without worrying about platform/compiler-specific differences (and having control over the timezone database).

diff --git a/include/date/date.h b/include/date/date.h                                     
index 6960e8c..602b7da 100644                                                              
--- a/include/date/date.h                                                                  
+++ b/include/date/date.h                                                                  
@@ -4228,7 +4228,7 @@ inline                                                               
 std::basic_ostream<CharT, Traits>&                                                        
 operator<<(std::basic_ostream<CharT, Traits>& os, const local_time<Duration>& ut)         
 {                                                                                         
-    return (os << sys_time<Duration>{ut.time_since_epoch()});                             
+    return date::operator<<(os, sys_time<Duration>{ut.time_since_epoch()});               
 }                                                                                         
                                                                                           
 namespace detail                                                                                                                                                                     
@HowardHinnant
Copy link
Owner

I'm very reluctant to start down this path. There are many places where this library will conflict with C++20 chrono. And I'm really not in a position to develop and maintain such a project. For cross-platform development I recommend a namespace alias that you can switch between date and std::chrono with a macro flag.

On control of the timezone database: I am working on a project to create my own database format, and (if successful) it will be interoperable with C++20's std::chrono::zoned_time. However it is still in the very early stages of development, and I'm still unsure if it will turn into a viable tool.

@tonygould
Copy link
Author

tonygould commented Jan 29, 2023

Understood. We use vcpkg and I have integrated the patch above into our local system. Once we have it working in our system, we will update the vcpkg port of date. As it stands, with the patch, all our tests of our code using the date library pass on both vs2019/C++17, vs2022/C++17 and 20. On linux, they pass on both gcc10.3/C++17 and gcc12.2/C++17 and 20. We are not using the timezone piece yet, but intend to.

Creation of your own database format sounds positive. We'd like to have our own control of the timezone database, i.e. decide when we update it rather than the config being "random" (e.g. when we happen to rebuild a docker image or when updates hit IANA). Running the date library in manual mode (I also intend to make manual mode available in the vcpkg port), reading in the current text files takes of the order of 20ms, which is pretty good actually :), but some sort of binary format would clearly be a win.

To be clear for cross-platform development, I want to use the exact same code on both platforms, i.e. your library. Even if it were acceptable to have the possibility of different algorithms for provision of timezone database on linux and windows, my understanding is that the database is not available until windows server 2022. And not until gcc 13 for linux (what I read of the gcc implementation looks great, e.g. the ability to parameterise where the database will be read from).

@HowardHinnant
Copy link
Owner

Thanks for all of this information. It is really helpful.

@tonygould
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants