DateTime conversion to tm problem?
Hi, The posix_time::to_tm function clears the date fields of the std::tm structure. Having zeros on year, month and day fields represent the 1900-01-00 date according to the std::tm conventions, which is a date that did not exist. Using such value with other APIs might result in out of range conditions. Is it considered to be a problem? What about setting tm_mday to 1 instead (which would represent 1900-01-01 - that is, the first legal date)? Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Maciej Sobczak wrote:
Hi,
The posix_time::to_tm function clears the date fields of the std::tm structure. Having zeros on year, month and day fields represent the 1900-01-00 date according to the std::tm conventions, which is a date that did not exist.
Which boost version do you use? In the current trunk version I see that posix_time::to_tm(ptime) calls gregorian::to_tm to initialize date portion of the tm structure. Or were you referring to posix_time::to_tm(time_duration)? If so then the comment explicitly says that the resulting tm structure has zeroed date portion. Considering that the original argument is duration, I think the function behavior is correct.
Maciej Sobczak wrote:
The posix_time::to_tm function clears the date fields of the std::tm structure. Having zeros on year, month and day fields represent the 1900-01-00 date according to the std::tm conventions, which is a date that did not exist. Using such value with other APIs might result in out of range conditions.
Is it considered to be a problem? What about setting tm_mday to 1 instead (which would represent 1900-01-01 - that is, the first legal date)?
Maybe if you show a use case your proposal will get more weight? Are there any use cases that will become invalid if the tm_mday will be set to 1?
Hello, Ilya Bobir wrote:
The posix_time::to_tm function clears the date fields of the std::tm structure. Having zeros on year, month and day fields represent the 1900-01-00 date according to the std::tm conventions, which is a date that did not exist. Using such value with other APIs might result in out of range conditions.
Is it considered to be a problem? What about setting tm_mday to 1 instead (which would represent 1900-01-01 - that is, the first legal date)?
Maybe if you show a use case your proposal will get more weight?
If you send this value to any API that expects a valid date, it might result in an error, because such date did not exist. Practical example - this was actually found when sending such value to the PostgreSQL database. I guess any other database is also "vulnerable" and also the way of sending it does not matter - it is the server itself that rejects the value, not any database interface. Independent on this practical example, the C standard defines the legal ranges of values for members of the tm structure and the tm_mday has the range [1,31]. I would argue that any code that sets it to zero is violating the standard.
Are there any use cases that will become invalid if the tm_mday will be set to 1?
Andrey Semashev noted that in the case of duration such a value is correct. I would argue, however, that duration and "point in time" should be distinct types - "overloading" std::tm for handling durations is a bad idea for the reasons explained above. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Maciej Sobczak wrote:
Are there any use cases that will become invalid if the tm_mday will be set to 1?
Andrey Semashev noted that in the case of duration such a value is correct. I would argue, however, that duration and "point in time" should be distinct types - "overloading" std::tm for handling durations is a bad idea for the reasons explained above.
That's right, but there's no standard type to express durations. And I agree, to_tm overload for time_duration might not have been a good idea. I guess, there was a good reason to provide it.
participants (3)
-
Andrey Semashev -
Ilya Bobir -
Maciej Sobczak