Converting ISO8601 string to milliseconds since epoch
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:
- strptime() and std::get_time() lose the millisecond precision
- More importantly, neither of those can deal with timezone offsets
- Some other solutions depend on 3P libraries
Is there some easy way to do this?
c++ c++14
|
show 7 more comments
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:
- strptime() and std::get_time() lose the millisecond precision
- More importantly, neither of those can deal with timezone offsets
- Some other solutions depend on 3P libraries
Is there some easy way to do this?
c++ c++14
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
|
show 7 more comments
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:
- strptime() and std::get_time() lose the millisecond precision
- More importantly, neither of those can deal with timezone offsets
- Some other solutions depend on 3P libraries
Is there some easy way to do this?
c++ c++14
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:
- strptime() and std::get_time() lose the millisecond precision
- More importantly, neither of those can deal with timezone offsets
- Some other solutions depend on 3P libraries
Is there some easy way to do this?
c++ c++14
c++ c++14
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
|
show 7 more comments
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
|
show 7 more comments
1 Answer
1
active
oldest
votes
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:
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.
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 aistringstream
. - 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 UTCtime_point
). - Extract and print out the
duration
of thetime_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<<;
.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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:
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.
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 aistringstream
. - 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 UTCtime_point
). - Extract and print out the
duration
of thetime_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<<;
.
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
add a comment |
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:
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.
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 aistringstream
. - 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 UTCtime_point
). - Extract and print out the
duration
of thetime_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<<;
.
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
add a comment |
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:
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.
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 aistringstream
. - 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 UTCtime_point
). - Extract and print out the
duration
of thetime_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<<;
.
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:
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.
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 aistringstream
. - 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 UTCtime_point
). - Extract and print out the
duration
of thetime_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<<;
.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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