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

P0355R7 <chrono> Calendars And Time Zones #12

Closed
StephanTLavavej opened this issue Sep 6, 2019 · 6 comments · Fixed by #1870
Closed

P0355R7 <chrono> Calendars And Time Zones #12

StephanTLavavej opened this issue Sep 6, 2019 · 6 comments · Fixed by #1870
Assignees
Labels
cxx20 C++20 feature fixed Something works now, yay!
Milestone

Comments

@StephanTLavavej
Copy link
Member

StephanTLavavej commented Sep 6, 2019

P0355R7 <chrono> Calendars And Time Zones
P1466R3 Miscellaneous Minor Fixes For <chrono>
P1650R0 Printing std::chrono::days With Suffix "d"
P1981R0 Renaming leap To leap_second
P1982R0 Renaming link To time_zone_link

LWG-3094 [time.duration.io]p4 makes surprising claims about encoding
LWG-3145 file_clock breaks ABI for C++17 implementations
LWG-3206 year_month_day conversion to sys_days uses not-existing member function
LWG-3209 Expression in year::ok() returns clause is ill-formed
LWG-3218 Modifier for %d parse flag does not match POSIX and format specification
LWG-3221 Result of year_month arithmetic with months is ambiguous
LWG-3224 zoned_time constructor from TimeZonePtr does not specify initialization of tp_
LWG-3225 zoned_time converting constructor shall not be noexcept
LWG-3226 zoned_time constructor from string_view should accept zoned_time<Duration2, TimeZonePtr2>
LWG-3230 Format specifier %y/%Y is missing locale alternative versions
LWG-3231 year_month_day_last::day specification does not cover !ok() values
LWG-3232 Inconsistency in zoned_time deduction guides
LWG-3235 parse manipulator without abbreviation is not callable
LWG-3241 chrono-spec grammar ambiguity in [time.format]
LWG-3245 Unnecessary restriction on '%p' parse specifier
LWG-3252 Parse locale's aware modifiers for commands are not consistent with POSIX spec
LWG-3260 year_month* arithmetic rejects durations convertible to years
LWG-3262 Formatting of negative durations is not specified
LWG-3269 Parse manipulators do not specify the result of the extraction from stream
LWG-3270 Parsing and formatting %j with durations
LWG-3272 %I%p should parse/format duration since midnight
LWG-3273 Specify weekday_indexed to range of [0, 7]
LWG-3294 zoned_time deduction guides misinterprets string/char*
LWG-3314 Is stream insertion behavior locale dependent when Period::type is micro?
LWG-3316 Correctly define epoch for utc_clock/utc_timepoint
LWG-3317 Incorrect operator<< for floating-point durations
LWG-3318 Clarify whether clocks can represent time before their epoch
LWG-3319 Properly reference specification of IANA time zone database
LWG-3332 [time.format] chrono-format-spec forgot q and Q
LWG-3359 <chrono> leap second support should allow for negative leap seconds
LWG-3383 [time.zone.leap.nonmembers] sys_seconds should be replaced with seconds

Feature-test macro as of WG21-N4842, increased by WG21-P1902:
#define __cpp_lib_chrono 201907L

@StephanTLavavej StephanTLavavej added the cxx20 C++20 feature label Sep 6, 2019
@SuperWig
Copy link
Contributor

Is someone working on this? I think I could partially implement this.
Though isn't this partially dependant on #30?

@StephanTLavavej
Copy link
Member Author

We haven't started working on this. Be aware that it's a major feature, one of the largest in C++20.

Yep, WG21-P1361 "Integrating <chrono> With <format>" links them (it's not a major dependency, as I understand it).

One of the things that we were planning to do is evaluate whether we should attempt to implement this from scratch, or incorporate an existing implementation. libc++'s implementation is in progress (according to their hopefully-accurate status page), while Howard Hinnant (the designer of chrono, and the original author of libc++) has an implementation of this feature, but we'd need to work out licensing.

@SuperWig
Copy link
Contributor

SuperWig commented Nov 14, 2019

Be aware that it's a major feature, one of the largest in C++20.

That's why I said partially ;). Though having had a quick look at what libc++ has implemented so far it's not a whole lot more that I was considering on implementing.

(basically, not the clocks and I/O/formatting)

@SuperWig
Copy link
Contributor

Well I've started working on it anway because I have too much free time on my hands and it's a fun learning experience 🤷‍♂

@SuperWig
Copy link
Contributor

@StephanTLavavej Quick question, when the standard says "Returns: expression" I shouldn't deviate from that at all, right?

@StephanTLavavej
Copy link
Member Author

Actually, the Standard’s As If Rule says that you can do anything you want, as long as the observable effects are “as if” you did exactly what the Standard says. For a Returns element (or the stronger Effects: Equivalent To), you generally should do what it says verbatim (with appropriate qualification etc.), but sometimes it is faster or better to do something different. If you do something different, you should comment it and/or call it out in your commit notes.

@cbezault cbezault added this to the Conformance milestone May 7, 2020
@StephanTLavavej StephanTLavavej linked a pull request May 17, 2020 that will close this issue
4 tasks
@StephanTLavavej StephanTLavavej added this to Reviewing PR in C++20 Features May 17, 2020
@mnatsuhara mnatsuhara self-assigned this Aug 25, 2020
@StephanTLavavej StephanTLavavej removed a link to a pull request Jan 30, 2021
4 tasks
@StephanTLavavej StephanTLavavej moved this from Reviewing PR to Investigating in C++20 Features Feb 2, 2021
@StephanTLavavej StephanTLavavej moved this from Investigating to Reviewing PR in C++20 Features Feb 22, 2021
@mnatsuhara mnatsuhara linked a pull request Mar 1, 2021 that will close this issue
@StephanTLavavej StephanTLavavej moved this from Reviewing PR to Investigating in C++20 Features Mar 19, 2021
@StephanTLavavej StephanTLavavej moved this from Investigating to Merging Soon in C++20 Features Apr 22, 2021
C++20 Features automation moved this from Merging Soon to Done Apr 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cxx20 C++20 feature fixed Something works now, yay!
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

4 participants