
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