2010/6/7 Paweł Blokus <[email protected]>: > Last issues :) - Date::to_tm and DateTime::to_tm, shouldn't they set > also the tm_yday and tm_wday parameters? Is it allowed for the > structure to have incoherent data in it?
Heh, well what is in there depends on what is used by the code (mostly in the /drizzled/function/time/ classes). If it's not used, those params probably aren't tested or set. > And what about the tm_isdst > flag? Same. timezones are handled by separate code (unfortunately) and so it is ignored. -jay > 2010/6/4 Jay Pipes <[email protected]>: >> On Fri, Jun 4, 2010 at 12:00 PM, Paweł Blokus <[email protected]> wrote: >>>> Subtracting a date from another date produces another date, not an >>>> interval. >>>> >>>> In any case, the code isn't used AFAIK. >>> >>> Does this mean it won't be in the future? Is this legacy code or is it >>> just meant to provide the full functionality in the library? >> >> I don't think it will be used in the future. Now that we use Boost, I >> would think that using >> Boost's datetime functionality would be a better solution in the future. >> >>> I've got also an additional question. In some cases DateTime and Time >>> are treated like they should have the microseconds component >>> (DateTime::to_string, and formats for both of them in >>> temporal_format.h) and in others like they shouldn't >>> (DateTime::is_valid, Time::to_string). So, what is the right way? >> >> The microsecond mess is due to some things we inherited from MySQL, >> which accounts for microseconds but only in certain cases, and it >> never *stores* microseconds in any data type. >> >> The right way is difficult to say, since what is in there is "the >> MySQL way" unless the MySQL way resulted in bad data input (not valid >> in the case of microseconds). So, what's in there passes tests for >> the MySQL test suite we inherited...and it was decided that we should >> correspond as much as possibly to the MySQL way of handling datetimes. >> >>> With exception of the above and some more advanced from_string tests >>> (which are ready, but the parameterized tests feature from google >>> tests isn't compiling for some reason) temporal.h is fully tested >> >> Awesome! Nice work! >> >> -jay >> > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
