Converting ISO8601 string to milliseconds since epoch












1















Sample string:




2018-10-31T14:45:21.778952-07:00




I would like to convert it to int64_t representing milliseconds (or even microseconds) since epoch. The timezone can vary. The code will be executing on a linux box, but I only have access to std and folly (cannot use any arbitrary 3P libraries).



I searched for this and found a few different ways that do not work for me:




  1. strptime() and std::get_time() lose the millisecond precision

  2. More importantly, neither of those can deal with timezone offsets

  3. Some other solutions depend on 3P libraries


Is there some easy way to do this?










share|improve this question

























  • I found following link. I hope it will be helpful. stackoverflow.com/questions/4137748/…

    – MJK
    Nov 13 '18 at 21:27











  • @MJK Sorry, should've mentioned I looked at that as well. Since std::get_time uses the tm struct, it loses the millisecond precision as well.

    – Pratik
    Nov 13 '18 at 22:01













  • Once you break apart each of the elements you might want to look into how OS’s convert the RTC into a unix epoch. The algorithms are pretty well known, and can usually be copied and pasted.

    – van dench
    Nov 13 '18 at 22:06











  • An example can be found here, the important part is converting a date to the number of days since 1970, I don’t remember where I originally found this information: forum.osdev.org/viewtopic.php?t=13635&p=93464

    – van dench
    Nov 13 '18 at 22:25






  • 1





    This particular problem doesn't require awareness of timezones since the UTC offset is part of the format. In case you change your mind on the use of Howard Hinnant's library, this problem requires only including a single header, and is only a few lines of code. This library has also already been voted into the C++20 working draft. And for the sample input, the result is 1541022321778952µs.

    – Howard Hinnant
    Nov 14 '18 at 14:04
















1















Sample string:




2018-10-31T14:45:21.778952-07:00




I would like to convert it to int64_t representing milliseconds (or even microseconds) since epoch. The timezone can vary. The code will be executing on a linux box, but I only have access to std and folly (cannot use any arbitrary 3P libraries).



I searched for this and found a few different ways that do not work for me:




  1. strptime() and std::get_time() lose the millisecond precision

  2. More importantly, neither of those can deal with timezone offsets

  3. Some other solutions depend on 3P libraries


Is there some easy way to do this?










share|improve this question

























  • I found following link. I hope it will be helpful. stackoverflow.com/questions/4137748/…

    – MJK
    Nov 13 '18 at 21:27











  • @MJK Sorry, should've mentioned I looked at that as well. Since std::get_time uses the tm struct, it loses the millisecond precision as well.

    – Pratik
    Nov 13 '18 at 22:01













  • Once you break apart each of the elements you might want to look into how OS’s convert the RTC into a unix epoch. The algorithms are pretty well known, and can usually be copied and pasted.

    – van dench
    Nov 13 '18 at 22:06











  • An example can be found here, the important part is converting a date to the number of days since 1970, I don’t remember where I originally found this information: forum.osdev.org/viewtopic.php?t=13635&p=93464

    – van dench
    Nov 13 '18 at 22:25






  • 1





    This particular problem doesn't require awareness of timezones since the UTC offset is part of the format. In case you change your mind on the use of Howard Hinnant's library, this problem requires only including a single header, and is only a few lines of code. This library has also already been voted into the C++20 working draft. And for the sample input, the result is 1541022321778952µs.

    – Howard Hinnant
    Nov 14 '18 at 14:04














1












1








1








Sample string:




2018-10-31T14:45:21.778952-07:00




I would like to convert it to int64_t representing milliseconds (or even microseconds) since epoch. The timezone can vary. The code will be executing on a linux box, but I only have access to std and folly (cannot use any arbitrary 3P libraries).



I searched for this and found a few different ways that do not work for me:




  1. strptime() and std::get_time() lose the millisecond precision

  2. More importantly, neither of those can deal with timezone offsets

  3. Some other solutions depend on 3P libraries


Is there some easy way to do this?










share|improve this question
















Sample string:




2018-10-31T14:45:21.778952-07:00




I would like to convert it to int64_t representing milliseconds (or even microseconds) since epoch. The timezone can vary. The code will be executing on a linux box, but I only have access to std and folly (cannot use any arbitrary 3P libraries).



I searched for this and found a few different ways that do not work for me:




  1. strptime() and std::get_time() lose the millisecond precision

  2. More importantly, neither of those can deal with timezone offsets

  3. Some other solutions depend on 3P libraries


Is there some easy way to do this?







c++ c++14






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 13 '18 at 23:26









rubenvb

53k22138259




53k22138259










asked Nov 13 '18 at 21:13









PratikPratik

128111




128111













  • I found following link. I hope it will be helpful. stackoverflow.com/questions/4137748/…

    – MJK
    Nov 13 '18 at 21:27











  • @MJK Sorry, should've mentioned I looked at that as well. Since std::get_time uses the tm struct, it loses the millisecond precision as well.

    – Pratik
    Nov 13 '18 at 22:01













  • Once you break apart each of the elements you might want to look into how OS’s convert the RTC into a unix epoch. The algorithms are pretty well known, and can usually be copied and pasted.

    – van dench
    Nov 13 '18 at 22:06











  • An example can be found here, the important part is converting a date to the number of days since 1970, I don’t remember where I originally found this information: forum.osdev.org/viewtopic.php?t=13635&p=93464

    – van dench
    Nov 13 '18 at 22:25






  • 1





    This particular problem doesn't require awareness of timezones since the UTC offset is part of the format. In case you change your mind on the use of Howard Hinnant's library, this problem requires only including a single header, and is only a few lines of code. This library has also already been voted into the C++20 working draft. And for the sample input, the result is 1541022321778952µs.

    – Howard Hinnant
    Nov 14 '18 at 14:04



















  • I found following link. I hope it will be helpful. stackoverflow.com/questions/4137748/…

    – MJK
    Nov 13 '18 at 21:27











  • @MJK Sorry, should've mentioned I looked at that as well. Since std::get_time uses the tm struct, it loses the millisecond precision as well.

    – Pratik
    Nov 13 '18 at 22:01













  • Once you break apart each of the elements you might want to look into how OS’s convert the RTC into a unix epoch. The algorithms are pretty well known, and can usually be copied and pasted.

    – van dench
    Nov 13 '18 at 22:06











  • An example can be found here, the important part is converting a date to the number of days since 1970, I don’t remember where I originally found this information: forum.osdev.org/viewtopic.php?t=13635&p=93464

    – van dench
    Nov 13 '18 at 22:25






  • 1





    This particular problem doesn't require awareness of timezones since the UTC offset is part of the format. In case you change your mind on the use of Howard Hinnant's library, this problem requires only including a single header, and is only a few lines of code. This library has also already been voted into the C++20 working draft. And for the sample input, the result is 1541022321778952µs.

    – Howard Hinnant
    Nov 14 '18 at 14:04

















I found following link. I hope it will be helpful. stackoverflow.com/questions/4137748/…

– MJK
Nov 13 '18 at 21:27





I found following link. I hope it will be helpful. stackoverflow.com/questions/4137748/…

– MJK
Nov 13 '18 at 21:27













@MJK Sorry, should've mentioned I looked at that as well. Since std::get_time uses the tm struct, it loses the millisecond precision as well.

– Pratik
Nov 13 '18 at 22:01







@MJK Sorry, should've mentioned I looked at that as well. Since std::get_time uses the tm struct, it loses the millisecond precision as well.

– Pratik
Nov 13 '18 at 22:01















Once you break apart each of the elements you might want to look into how OS’s convert the RTC into a unix epoch. The algorithms are pretty well known, and can usually be copied and pasted.

– van dench
Nov 13 '18 at 22:06





Once you break apart each of the elements you might want to look into how OS’s convert the RTC into a unix epoch. The algorithms are pretty well known, and can usually be copied and pasted.

– van dench
Nov 13 '18 at 22:06













An example can be found here, the important part is converting a date to the number of days since 1970, I don’t remember where I originally found this information: forum.osdev.org/viewtopic.php?t=13635&p=93464

– van dench
Nov 13 '18 at 22:25





An example can be found here, the important part is converting a date to the number of days since 1970, I don’t remember where I originally found this information: forum.osdev.org/viewtopic.php?t=13635&p=93464

– van dench
Nov 13 '18 at 22:25




1




1





This particular problem doesn't require awareness of timezones since the UTC offset is part of the format. In case you change your mind on the use of Howard Hinnant's library, this problem requires only including a single header, and is only a few lines of code. This library has also already been voted into the C++20 working draft. And for the sample input, the result is 1541022321778952µs.

– Howard Hinnant
Nov 14 '18 at 14:04





This particular problem doesn't require awareness of timezones since the UTC offset is part of the format. In case you change your mind on the use of Howard Hinnant's library, this problem requires only including a single header, and is only a few lines of code. This library has also already been voted into the C++20 working draft. And for the sample input, the result is 1541022321778952µs.

– Howard Hinnant
Nov 14 '18 at 14:04












1 Answer
1






active

oldest

votes


















3














From the comments above:




I am looking into using Howard's library. However, that it makes a web call gives me pause. I assume that if the call fails it will just use the locally stored timezone name data? We won't be dealing with timezone names, so I don't care about those. However, making a network call might be an issue.




Howard's library is layered:




  1. A foundational layer that does not need the IANA time zone database and thus never makes networking calls. This is a single header, header-only library.


  2. A time zone layer that is aware of the IANA time zone database. This layer can be configured to make network calls or not (depending on build flags), or even use your OS's time zone database (except on Windows).



Your application does not require the time zone layer as it only deals with UTC offsets, and not time zone names or rules.



Here is a function that converts a std::string with your sample format into a std::chrono::time_point<std::chrono::system_clock, std::chrono::microseconds>. That type is a big verbose mouthful for a system_clock::time_point except guaranteed to have microseconds precision. The foundational layer has a type alias for this type called date::sys_time<std::chrono::microseconds>.



#include "date/date.h"
#include <chrono>
#include <iostream>
#include <sstream>

auto
to_sys_time(std::string s)
{
using namespace date;
using namespace std;
using namespace std::chrono;
istringstream in{move(s)};
in.exceptions(ios::failbit);
sys_time<microseconds> tp;
in >> parse("%FT%T%z", tp);
return tp;
}



  • Put the string into a istringstream.

  • Optionally set the istringstream to throw an exception if it fails to parse something (you may choose to handle errors differently).

  • Declare your time_point with the desired precision.

  • Parse it with your desired format.

  • Return it.


You can exercise this function like so:



int
main()
{
auto tp = to_sys_time("2018-10-31T14:45:21.778952-07:00");
using date::operator<<;
std::cout << tp << " UTCn";
std::cout << tp.time_since_epoch() << 'n';
}



  • Call to_sys_time with the desired input string.

  • Make the streaming operators in namespace date available.

  • Print out the time_point (this is a UTC time_point).

  • Extract and print out the duration of the time_point.


The output of this program is:



2018-10-31 21:45:21.778952 UTC
1541022321778952µs


Currently this program will port to the C++20 draft spec by removing #include "date/date.h", using namespace date; and using date::operator<<;.






share|improve this answer



















  • 1





    Thanks, Howard! The right answer is that C++14 standard library does not have a way to parse the timezone offset, and so my only option is to either write that logic myself or use a 3P library. Your library is the best option.

    – Pratik
    Nov 16 '18 at 19:09











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53289574%2fconverting-iso8601-string-to-milliseconds-since-epoch%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














From the comments above:




I am looking into using Howard's library. However, that it makes a web call gives me pause. I assume that if the call fails it will just use the locally stored timezone name data? We won't be dealing with timezone names, so I don't care about those. However, making a network call might be an issue.




Howard's library is layered:




  1. A foundational layer that does not need the IANA time zone database and thus never makes networking calls. This is a single header, header-only library.


  2. A time zone layer that is aware of the IANA time zone database. This layer can be configured to make network calls or not (depending on build flags), or even use your OS's time zone database (except on Windows).



Your application does not require the time zone layer as it only deals with UTC offsets, and not time zone names or rules.



Here is a function that converts a std::string with your sample format into a std::chrono::time_point<std::chrono::system_clock, std::chrono::microseconds>. That type is a big verbose mouthful for a system_clock::time_point except guaranteed to have microseconds precision. The foundational layer has a type alias for this type called date::sys_time<std::chrono::microseconds>.



#include "date/date.h"
#include <chrono>
#include <iostream>
#include <sstream>

auto
to_sys_time(std::string s)
{
using namespace date;
using namespace std;
using namespace std::chrono;
istringstream in{move(s)};
in.exceptions(ios::failbit);
sys_time<microseconds> tp;
in >> parse("%FT%T%z", tp);
return tp;
}



  • Put the string into a istringstream.

  • Optionally set the istringstream to throw an exception if it fails to parse something (you may choose to handle errors differently).

  • Declare your time_point with the desired precision.

  • Parse it with your desired format.

  • Return it.


You can exercise this function like so:



int
main()
{
auto tp = to_sys_time("2018-10-31T14:45:21.778952-07:00");
using date::operator<<;
std::cout << tp << " UTCn";
std::cout << tp.time_since_epoch() << 'n';
}



  • Call to_sys_time with the desired input string.

  • Make the streaming operators in namespace date available.

  • Print out the time_point (this is a UTC time_point).

  • Extract and print out the duration of the time_point.


The output of this program is:



2018-10-31 21:45:21.778952 UTC
1541022321778952µs


Currently this program will port to the C++20 draft spec by removing #include "date/date.h", using namespace date; and using date::operator<<;.






share|improve this answer



















  • 1





    Thanks, Howard! The right answer is that C++14 standard library does not have a way to parse the timezone offset, and so my only option is to either write that logic myself or use a 3P library. Your library is the best option.

    – Pratik
    Nov 16 '18 at 19:09
















3














From the comments above:




I am looking into using Howard's library. However, that it makes a web call gives me pause. I assume that if the call fails it will just use the locally stored timezone name data? We won't be dealing with timezone names, so I don't care about those. However, making a network call might be an issue.




Howard's library is layered:




  1. A foundational layer that does not need the IANA time zone database and thus never makes networking calls. This is a single header, header-only library.


  2. A time zone layer that is aware of the IANA time zone database. This layer can be configured to make network calls or not (depending on build flags), or even use your OS's time zone database (except on Windows).



Your application does not require the time zone layer as it only deals with UTC offsets, and not time zone names or rules.



Here is a function that converts a std::string with your sample format into a std::chrono::time_point<std::chrono::system_clock, std::chrono::microseconds>. That type is a big verbose mouthful for a system_clock::time_point except guaranteed to have microseconds precision. The foundational layer has a type alias for this type called date::sys_time<std::chrono::microseconds>.



#include "date/date.h"
#include <chrono>
#include <iostream>
#include <sstream>

auto
to_sys_time(std::string s)
{
using namespace date;
using namespace std;
using namespace std::chrono;
istringstream in{move(s)};
in.exceptions(ios::failbit);
sys_time<microseconds> tp;
in >> parse("%FT%T%z", tp);
return tp;
}



  • Put the string into a istringstream.

  • Optionally set the istringstream to throw an exception if it fails to parse something (you may choose to handle errors differently).

  • Declare your time_point with the desired precision.

  • Parse it with your desired format.

  • Return it.


You can exercise this function like so:



int
main()
{
auto tp = to_sys_time("2018-10-31T14:45:21.778952-07:00");
using date::operator<<;
std::cout << tp << " UTCn";
std::cout << tp.time_since_epoch() << 'n';
}



  • Call to_sys_time with the desired input string.

  • Make the streaming operators in namespace date available.

  • Print out the time_point (this is a UTC time_point).

  • Extract and print out the duration of the time_point.


The output of this program is:



2018-10-31 21:45:21.778952 UTC
1541022321778952µs


Currently this program will port to the C++20 draft spec by removing #include "date/date.h", using namespace date; and using date::operator<<;.






share|improve this answer



















  • 1





    Thanks, Howard! The right answer is that C++14 standard library does not have a way to parse the timezone offset, and so my only option is to either write that logic myself or use a 3P library. Your library is the best option.

    – Pratik
    Nov 16 '18 at 19:09














3












3








3







From the comments above:




I am looking into using Howard's library. However, that it makes a web call gives me pause. I assume that if the call fails it will just use the locally stored timezone name data? We won't be dealing with timezone names, so I don't care about those. However, making a network call might be an issue.




Howard's library is layered:




  1. A foundational layer that does not need the IANA time zone database and thus never makes networking calls. This is a single header, header-only library.


  2. A time zone layer that is aware of the IANA time zone database. This layer can be configured to make network calls or not (depending on build flags), or even use your OS's time zone database (except on Windows).



Your application does not require the time zone layer as it only deals with UTC offsets, and not time zone names or rules.



Here is a function that converts a std::string with your sample format into a std::chrono::time_point<std::chrono::system_clock, std::chrono::microseconds>. That type is a big verbose mouthful for a system_clock::time_point except guaranteed to have microseconds precision. The foundational layer has a type alias for this type called date::sys_time<std::chrono::microseconds>.



#include "date/date.h"
#include <chrono>
#include <iostream>
#include <sstream>

auto
to_sys_time(std::string s)
{
using namespace date;
using namespace std;
using namespace std::chrono;
istringstream in{move(s)};
in.exceptions(ios::failbit);
sys_time<microseconds> tp;
in >> parse("%FT%T%z", tp);
return tp;
}



  • Put the string into a istringstream.

  • Optionally set the istringstream to throw an exception if it fails to parse something (you may choose to handle errors differently).

  • Declare your time_point with the desired precision.

  • Parse it with your desired format.

  • Return it.


You can exercise this function like so:



int
main()
{
auto tp = to_sys_time("2018-10-31T14:45:21.778952-07:00");
using date::operator<<;
std::cout << tp << " UTCn";
std::cout << tp.time_since_epoch() << 'n';
}



  • Call to_sys_time with the desired input string.

  • Make the streaming operators in namespace date available.

  • Print out the time_point (this is a UTC time_point).

  • Extract and print out the duration of the time_point.


The output of this program is:



2018-10-31 21:45:21.778952 UTC
1541022321778952µs


Currently this program will port to the C++20 draft spec by removing #include "date/date.h", using namespace date; and using date::operator<<;.






share|improve this answer













From the comments above:




I am looking into using Howard's library. However, that it makes a web call gives me pause. I assume that if the call fails it will just use the locally stored timezone name data? We won't be dealing with timezone names, so I don't care about those. However, making a network call might be an issue.




Howard's library is layered:




  1. A foundational layer that does not need the IANA time zone database and thus never makes networking calls. This is a single header, header-only library.


  2. A time zone layer that is aware of the IANA time zone database. This layer can be configured to make network calls or not (depending on build flags), or even use your OS's time zone database (except on Windows).



Your application does not require the time zone layer as it only deals with UTC offsets, and not time zone names or rules.



Here is a function that converts a std::string with your sample format into a std::chrono::time_point<std::chrono::system_clock, std::chrono::microseconds>. That type is a big verbose mouthful for a system_clock::time_point except guaranteed to have microseconds precision. The foundational layer has a type alias for this type called date::sys_time<std::chrono::microseconds>.



#include "date/date.h"
#include <chrono>
#include <iostream>
#include <sstream>

auto
to_sys_time(std::string s)
{
using namespace date;
using namespace std;
using namespace std::chrono;
istringstream in{move(s)};
in.exceptions(ios::failbit);
sys_time<microseconds> tp;
in >> parse("%FT%T%z", tp);
return tp;
}



  • Put the string into a istringstream.

  • Optionally set the istringstream to throw an exception if it fails to parse something (you may choose to handle errors differently).

  • Declare your time_point with the desired precision.

  • Parse it with your desired format.

  • Return it.


You can exercise this function like so:



int
main()
{
auto tp = to_sys_time("2018-10-31T14:45:21.778952-07:00");
using date::operator<<;
std::cout << tp << " UTCn";
std::cout << tp.time_since_epoch() << 'n';
}



  • Call to_sys_time with the desired input string.

  • Make the streaming operators in namespace date available.

  • Print out the time_point (this is a UTC time_point).

  • Extract and print out the duration of the time_point.


The output of this program is:



2018-10-31 21:45:21.778952 UTC
1541022321778952µs


Currently this program will port to the C++20 draft spec by removing #include "date/date.h", using namespace date; and using date::operator<<;.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 16 '18 at 3:38









Howard HinnantHoward Hinnant

141k28310435




141k28310435








  • 1





    Thanks, Howard! The right answer is that C++14 standard library does not have a way to parse the timezone offset, and so my only option is to either write that logic myself or use a 3P library. Your library is the best option.

    – Pratik
    Nov 16 '18 at 19:09














  • 1





    Thanks, Howard! The right answer is that C++14 standard library does not have a way to parse the timezone offset, and so my only option is to either write that logic myself or use a 3P library. Your library is the best option.

    – Pratik
    Nov 16 '18 at 19:09








1




1





Thanks, Howard! The right answer is that C++14 standard library does not have a way to parse the timezone offset, and so my only option is to either write that logic myself or use a 3P library. Your library is the best option.

– Pratik
Nov 16 '18 at 19:09





Thanks, Howard! The right answer is that C++14 standard library does not have a way to parse the timezone offset, and so my only option is to either write that logic myself or use a 3P library. Your library is the best option.

– Pratik
Nov 16 '18 at 19:09


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53289574%2fconverting-iso8601-string-to-milliseconds-since-epoch%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Xamarin.iOS Cant Deploy on Iphone

Glorious Revolution

Dulmage-Mendelsohn matrix decomposition in Python