HowardHinnant/date
1
0
Fork 1
mirror of https://github.com/HowardHinnant/date.git synced 2025-08-05 05:34:27 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated Examples and Recipes (markdown)

Howard Hinnant
2016-07-07 21:59:21 -04:00
parent 8fe4a23192
commit 7d74a91aa3
1 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
Examples-and-Recipes.md

@@ -134,16 +134,18 @@ Then just print it out:
Obviously you could just as easily specify the meeting in Moscow's time zone and then find the equivalent time in New York: Obviously you could just as easily specify the meeting in Moscow's time zone and then find the equivalent time in New York:
auto moscow = make_zoned("Europe/Moscow", local_days{jul/7/2016} + 16h); auto moscow = make_zoned("Europe/Moscow", local_days{7_d/jul/2016} + 16h);
auto ny = make_zoned("America/New_York", moscow); auto ny = make_zoned("America/New_York", moscow);
This would result in the exact same output. This would result in the exact same output. For those paying attention, I reordered the date from m/d/y to d/m/y just to show that I could. The meaning is the same.
Sometimes it is convenient to specify the time independent of either timezone. For example this might be some celestial event such as an eclipse. Often such events are recorded in UTC so that people in all time zones can more easily know the correct time. It is just as easy to use UTC for this example: Sometimes it is convenient to specify the time independent of either timezone. For example this might be some celestial event such as an eclipse. Often such events are recorded in UTC so that people in all time zones can more easily know the correct time. It is just as easy to use UTC for this example:
auto utc = sys_days{jul/7/2016} + 13h; auto utc = sys_days{2016_y/jul/7} + 13h;
auto ny = make_zoned("America/New_York", utc); auto ny = make_zoned("America/New_York", utc);
auto moscow = make_zoned("Europe/Moscow", utc); auto moscow = make_zoned("Europe/Moscow", etc);
I reordered the date to y/m/d just to show that I could. As long as the first unit is unambiguous (`year`, `month` or `day`), the following two are unambiguous (only `y/m/d`, `d/m/y` and `m/d/y` are accepted; all others are rejected at compile time).
Instead of `local_days`, `sys_days` is used instead. `sys_days` means UTC (technically it means [Unix Time](https://en.wikipedia.org/wiki/Unix_time) which is a very close approximation to UTC). Then you can construct each `zoned_time` with the UTC time (which has type `sys_time<hours>` in this example). You could also construct the second `zoned_time` from the first, just as before: Instead of `local_days`, `sys_days` is used instead. `sys_days` means UTC (technically it means [Unix Time](https://en.wikipedia.org/wiki/Unix_time) which is a very close approximation to UTC). Then you can construct each `zoned_time` with the UTC time (which has type `sys_time<hours>` in this example). You could also construct the second `zoned_time` from the first, just as before: