{"action":"created","issue":{"url":"https://api.github.com/repos/HowardHinnant/date/issues/173","repository_url":"https://api.github.com/repos/HowardHinnant/date","labels_url":"https://api.github.com/repos/HowardHinnant/date/issues/173/labels{/name}","comments_url":"https://api.github.com/repos/HowardHinnant/date/issues/173/comments","events_url":"https://api.github.com/repos/HowardHinnant/date/issues/173/events","html_url":"https://github.com/HowardHinnant/date/issues/173","id":242451317,"number":173,"title":"Support for time_point + offset","user":{"login":"d-frey","id":3956325,"avatar_url":"https://avatars6.githubusercontent.com/u/3956325?v=4","gravatar_id":"","url":"https://api.github.com/users/d-frey","html_url":"https://github.com/d-frey","followers_url":"https://api.github.com/users/d-frey/followers","following_url":"https://api.github.com/users/d-frey/following{/other_user}","gists_url":"https://api.github.com/users/d-frey/gists{/gist_id}","starred_url":"https://api.github.com/users/d-frey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/d-frey/subscriptions","organizations_url":"https://api.github.com/users/d-frey/orgs","repos_url":"https://api.github.com/users/d-frey/repos","events_url":"https://api.github.com/users/d-frey/events{/privacy}","received_events_url":"https://api.github.com/users/d-frey/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2017-07-12T17:07:16Z","updated_at":"2017-07-14T15:51:10Z","closed_at":null,"body":"Some use-cases (for example trying to implement/use [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt)) require a time_point with a UTC offset. An offset is not a time-zone as several time-zones can share the same offset. What I'm asking for is a layer in between `sys_time`/`local_time` and `zoned_time`, maybe called `offset_time`.\r\n\r\nIt would be nice to have support for `offset_time` in `date.h`, as `tz.h` requires `tz.cpp` (hence not being suitable for a header-only library) and the latter also carries quite some overhead which offset-based timestamps don't need.\r\n"},"comment":{"url":"https://api.github.com/repos/HowardHinnant/date/issues/comments/315395142","html_url":"https://github.com/HowardHinnant/date/issues/173#issuecomment-315395142","issue_url":"https://api.github.com/repos/HowardHinnant/date/issues/173","id":315395142,"user":{"login":"d-frey","id":3956325,"avatar_url":"https://avatars6.githubusercontent.com/u/3956325?v=4","gravatar_id":"","url":"https://api.github.com/users/d-frey","html_url":"https://github.com/d-frey","followers_url":"https://api.github.com/users/d-frey/followers","following_url":"https://api.github.com/users/d-frey/following{/other_user}","gists_url":"https://api.github.com/users/d-frey/gists{/gist_id}","starred_url":"https://api.github.com/users/d-frey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/d-frey/subscriptions","organizations_url":"https://api.github.com/users/d-frey/orgs","repos_url":"https://api.github.com/users/d-frey/repos","events_url":"https://api.github.com/users/d-frey/events{/privacy}","received_events_url":"https://api.github.com/users/d-frey/received_events","type":"User","site_admin":false},"created_at":"2017-07-14T15:51:10Z","updated_at":"2017-07-14T15:51:10Z","body":"One thing that \"clicked\" in my head is that a time_point is really a duration relative to a \"fixed\" reference point in time. Now, `clock` might be the wrong name for the first template parameter of `time_point`, given that `local_t` is not really a clock already. It is an unspecified abstract reference point that later needs to be combined with an actual reference point (UTC, TAI, GPS, ...) to make sense.\r\n\r\nAnyways, if I follow this thought, I could create an offset_clock with a fixed offset given as a template parameter as you suggested. However, I can not create an offset_clock which stores a runtime-value for the offset, as the `time_point` will not store an instance of a clock, it just uses the clock as a template parameter.\r\n\r\nIs it too far of a stretch to think that the clock should be more like an allocator, meaning that a `time_point` should store an instance of a clock (of course optimized away if the clock class is an empty class)? The clock could then store its own data (like an adjustable offset towards UTC) and some methods should be used to route conversions through it. (or should this be done elsewhere?)\r\n\r\n> Or you could make the offset a run time property of offset_clock, and provide inter convertibility between time_points with different offsets.\r\n\r\nWithout the `time_point` storing an instance of the clock, I do not see how the above would be possible. Did you have some other design in mind that I do not see?\r\n"}}
{"actor":{"display_login":"d-frey"}}