Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input date modified when calling mktime64 #7

Open
tucanus opened this issue Oct 1, 2014 · 5 comments
Open

Input date modified when calling mktime64 #7

tucanus opened this issue Oct 1, 2014 · 5 comments

Comments

@tucanus
Copy link

tucanus commented Oct 1, 2014

Congratulations for this great lib, solved me a sad moment.
I noticed mktime64 correct input_date, but leaving an incorrect year if date is not in safe range.
I modified sources, adding

    /* correct variation of year on input_date */
    input_date->tm_year = year - date.tm_year + safe_date.tm_year - 1900;

after line 542 (copying safe_date on input_date) and it seems to work correctly.
Do you think it is acceptable?
Thank you for your job
-Cristiano

@schwern
Copy link
Collaborator

schwern commented Jan 5, 2015

Could you provide a sample program that triggers the bug? Be sure to include the time zone you're in.

@tucanus
Copy link
Author

tucanus commented Mar 13, 2015

Sure.

#include <iostream>
#include "time64.h"

int main(int argc, char **argv) {
    struct tm tt;
    char buffer[64];
    ::strptime("1/1/2040 12.00.00", "%d/%m/%Y %H.%M.%S", &tt);
    {
        size_t len = ::strftime(buffer, sizeof(buffer), "%d/%m/%Y %H.%M.%S", &tt);
        std::cout << "Input date: " << std::string(buffer, len) << std::endl;
    }
    ::mktime64((struct TM *)&tt);
    {
        size_t len = ::strftime(buffer, sizeof(buffer), "%d/%m/%Y %H.%M.%S", &tt);
        std::cout << "Correct date: " << std::string(buffer, len) << std::endl;
    }
    return 0;
}

Output

Input date: 01/01/2040 12.00.00
Correct date: 01/01/2012 12.00.00

Excuse but I have not understood where I have to include my time zone. I ran this code at CET, if you need to know.

@schwern
Copy link
Collaborator

schwern commented Dec 11, 2015

I haven't forgotten about this. I'm off learning a bunch of C so I can do a better job fixing up this project. LMK if there's urgency on getting this integrated.

@VTiTux
Copy link

VTiTux commented Jan 9, 2019

Same issue.
Enter 2038/01/19 3:00:00, return 2010/01/19 3:00:00

@liquidaty
Copy link

FYI to workaround this issue, I just commented out the two lines in mktime64 which call copy_tm_to_TM64. Not sure why they are there to begin with but perhaps the author could opine on whether they should stay? If they should, then an alternative workaround would be to revert the year immediately after the second occurrence of copy_tm_to_TM64:

    /* Have to make the year safe in date else it won't fit in safe_date */
    date = *input_date;
[...]
    /* Correct the user's possibly out of bound input date */
    copy_tm_to_TM64(&safe_date, input_date);
+
+    /* revert the year to the original value */
+    input_date->tm_year = year - 1900;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants