Getting todays date and adding 24hrs

[dhayden]

With respect to date-time stuff, it means you can manipulate time_points with high abstractions instead of lots of code playing around with lots of lines of std::tm stuff.

But that isn't the case for the simple example that we're talking about here. I didn't mean to imply that modern C++ is inferior at manipulating time in all circumstances. I just mean that for this simple example, I prefer the simple solution to the highly abstract one.

[Duthomhas]

That works. I dislike messing with it at all, honestly. :O)

[MikeStgt]

most systems properly handle DST with localtime()

I wonder that in this thread about timestamp when a ticked is activated and a second one when the 24 hrs valid period ends, obviously nobody asked up to now if DST is respected. In almost 363 if 365 cases this does not matter, but at least for the transition from normal time to DST the ticket buyer (the client!) could complain about the lost hr. (A solution could be similar to the duration of sabbath, you know when it starts and when it ends next day, but because it is so enjoyable it lasts 25 hrs. To avoid any trouble also the 24 hrs ticket could be valid 25 hrs all year but for the transition from DST back to normal time.)

Question: "most systems properly handle DST with localtime()" -- what exactly is included within this "properly handle"? At least correct setting of alarms according appointments in PIM (like HP200LX once upon a time) I hope. But also now+24hrs? The description and the example I found here -- http://www.cplusplus.com/reference/ctime/localtime is not adequate (for me). Another so-called documentation just states "The function localtime() converts calendar time time into local time." Aha. Not a scrap about DST.
My recommendation: ignore DST and extend the small print/legal copy on that ticket.