Re: [boost] date_time: local_date_time small fix
[mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland
Actually it's intentional to not do an automatic conversion there. Call utc_time() to get the ptime.
Could you explains the reasons? I see 2 problems with this approach: 1. creation of ptime object on stack, why? 2. Base class already has those operators, so why do you hide them?
Jeff _______________________________________________
Thanks Roman Yakovenko
On Mon, 28 Nov 2005 15:26:54 +0200, Roman Yakovenko wrote
[mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland
Actually it's intentional to not do an automatic conversion there. Call utc_time() to get the ptime.
Could you explains the reasons?
The user needs to think about what is being compared. ptime doesn't carry along a timezone so it could represent a utc_time or a locally adjusted time -- only the users knows which it is. By explicity asking to compare against utc_time() or local_time() the code intent should be clearer. So you basically have 2 options for the compare: local_date_time l_time(...); ptime t(...); if (t == l_time.utc_time()) OR if (t == l_time.local_time())
I see 2 problems with this approach:
1. creation of ptime object on stack, why?
It's at most a couple ints....usually just a 64 bit int, I think you can afford it.
2. Base class already has those operators, so why do you hide them?
Unless I'm missing something the base class provides for comparison to other local times not ptimes: local_date_time l_time1(...), l_time2(...); if (ltime_1 == ltime_2) {... Jeff
participants (2)
-
Jeff Garland -
Roman Yakovenko