CODEWITHSUNDEEP
c++cwindowsdatetimeepoch
khrist safalhai
khrist safalhai

Reputation: 570

Representing dates before epoch

We have a bespoke datetime C++ class which represents time in number of seconds passed since epoch. This is stored as int64. This class provides number of helper functions to read and write various types of datetime formats.

Unfortunately it cant handle dates before epoch because its methods rely on gmtime() and mktime() for many operations, which on our windows system does not support dates before epoch. Does anyone knows of replacement of gmtime and mktime which support negative values on windows.

An example of this limitation is our applicatio's inability to store birthdays before 1970, that is because every date has to use this class.

I amy not be clear on what I am asking, this is because of my limited knowledge of datetime implementation/use and my reluctance to understand that huge legacy class, so if you feel this question can be framed in another way or I might look for something different feel free to suggest.

Upvotes: 4

Views: 2120

Answers (3)

Howard Hinnant
Howard Hinnant

Reputation: 218890

Coming soon to a std::lib implementation near you:

#include <chrono>
#include <iostream>

int
main()
{
    using namespace std::chrono;
    std::cout << "Valid range is ["
              << sys_days{year::min()/January/1} + 0us << ", "
              << sys_days{year::max()/December/31} + 23h + 59min + 59s + 999'999us
              << "]\n";
}

Output:

Valid range is [-32767-01-01 00:00:00.000000, 32767-12-31 23:59:59.999999]

Preview available here.

Upvotes: 0

mwag
mwag

Reputation: 4035

Maybe you've solved this problem already since it was years ago, but you could also use ICU. Examples at: http://userguide.icu-project.org/datetime/calendar/examples

Upvotes: 0

Steve Townsend
Steve Townsend

Reputation: 54168

You could use Boost.DateTime, or use the Win32 APIs directly rather than the CRT.

It's likely that you have a lot of testing ahead of you to ensure that handling of data does not change in your rework. Make sure you have exhaustive unit tests in place for the library as it stands before you begin any refactoring.

If you have to consider your values being valid across multiple different locations in the world, use UTC time as your canonical form and translate to/from local time as needed for sensible input/display.

Upvotes: 3

Related Questions