Get current timestamp from yyyy-mm-dd hh:mm:ss using UTC/GMT+0 as epoch
I've tried a lot from this community but it seems like there's no hyper specific scenario for my case.
So basically I have a string in the format of yyyy-mm-dd
. I use date methods to adjust it and add time on the date to make it more specific. I want to convert it to timestamp while ignoring the client computer's current timezone (or using UTC timezone).
I have this code:
function getTimestampRange(sparams, eparams)
sparams = "2018-11-12", eparams = "2018-11-13"; //sample param values
const start = sparams.split("-");
const end = eparams.split("-");
const startDate = new Date(start[0], start[1] - 1, start[2]);
const endDate = new Date(end[0], end[1] - 1, end[2]);
endDate.setHours(23);
endDate.setMinutes(59);
endDate.setSeconds(59);
//startDate is 2018-11-12 00:00:00 and endDate is 2018-11-13 23:59:59
const startTS = startDate.getTime() / 1000;
const endTS = endDate.getTime() / 1000;
return [startTS, endTS]
This is all fine and dandy but the problem is, I'm getting the timestamp relative to my computer's timezone. (GMT+9). So my epoch is the 9th hour of 1970-01-01. Which is not what I need. I need the GMT+0 UTC timestamp.
In this scenario, I'd get 1541948400
and 1542121199
, start and end respectively; where I should be getting 1541980800
and 1542153599
.
Tasukete kudasai
javascript date timestamp epoch
add a comment |
I've tried a lot from this community but it seems like there's no hyper specific scenario for my case.
So basically I have a string in the format of yyyy-mm-dd
. I use date methods to adjust it and add time on the date to make it more specific. I want to convert it to timestamp while ignoring the client computer's current timezone (or using UTC timezone).
I have this code:
function getTimestampRange(sparams, eparams)
sparams = "2018-11-12", eparams = "2018-11-13"; //sample param values
const start = sparams.split("-");
const end = eparams.split("-");
const startDate = new Date(start[0], start[1] - 1, start[2]);
const endDate = new Date(end[0], end[1] - 1, end[2]);
endDate.setHours(23);
endDate.setMinutes(59);
endDate.setSeconds(59);
//startDate is 2018-11-12 00:00:00 and endDate is 2018-11-13 23:59:59
const startTS = startDate.getTime() / 1000;
const endTS = endDate.getTime() / 1000;
return [startTS, endTS]
This is all fine and dandy but the problem is, I'm getting the timestamp relative to my computer's timezone. (GMT+9). So my epoch is the 9th hour of 1970-01-01. Which is not what I need. I need the GMT+0 UTC timestamp.
In this scenario, I'd get 1541948400
and 1542121199
, start and end respectively; where I should be getting 1541980800
and 1542153599
.
Tasukete kudasai
javascript date timestamp epoch
1
" I want to convert it to timestamp while ignoring the client computer's current timezone" 👈 timestamps are timezone agnostic. They reflect the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z
– Phil
Nov 13 '18 at 2:53
@Phil I don't know how to properly phrase it but I get a different timestamp on this method, which is a very simple algorithm. When I convert the timestamp that I get in this method, it's always 9 hours ahead of UTC
– Abana Clara
Nov 13 '18 at 2:56
add a comment |
I've tried a lot from this community but it seems like there's no hyper specific scenario for my case.
So basically I have a string in the format of yyyy-mm-dd
. I use date methods to adjust it and add time on the date to make it more specific. I want to convert it to timestamp while ignoring the client computer's current timezone (or using UTC timezone).
I have this code:
function getTimestampRange(sparams, eparams)
sparams = "2018-11-12", eparams = "2018-11-13"; //sample param values
const start = sparams.split("-");
const end = eparams.split("-");
const startDate = new Date(start[0], start[1] - 1, start[2]);
const endDate = new Date(end[0], end[1] - 1, end[2]);
endDate.setHours(23);
endDate.setMinutes(59);
endDate.setSeconds(59);
//startDate is 2018-11-12 00:00:00 and endDate is 2018-11-13 23:59:59
const startTS = startDate.getTime() / 1000;
const endTS = endDate.getTime() / 1000;
return [startTS, endTS]
This is all fine and dandy but the problem is, I'm getting the timestamp relative to my computer's timezone. (GMT+9). So my epoch is the 9th hour of 1970-01-01. Which is not what I need. I need the GMT+0 UTC timestamp.
In this scenario, I'd get 1541948400
and 1542121199
, start and end respectively; where I should be getting 1541980800
and 1542153599
.
Tasukete kudasai
javascript date timestamp epoch
I've tried a lot from this community but it seems like there's no hyper specific scenario for my case.
So basically I have a string in the format of yyyy-mm-dd
. I use date methods to adjust it and add time on the date to make it more specific. I want to convert it to timestamp while ignoring the client computer's current timezone (or using UTC timezone).
I have this code:
function getTimestampRange(sparams, eparams)
sparams = "2018-11-12", eparams = "2018-11-13"; //sample param values
const start = sparams.split("-");
const end = eparams.split("-");
const startDate = new Date(start[0], start[1] - 1, start[2]);
const endDate = new Date(end[0], end[1] - 1, end[2]);
endDate.setHours(23);
endDate.setMinutes(59);
endDate.setSeconds(59);
//startDate is 2018-11-12 00:00:00 and endDate is 2018-11-13 23:59:59
const startTS = startDate.getTime() / 1000;
const endTS = endDate.getTime() / 1000;
return [startTS, endTS]
This is all fine and dandy but the problem is, I'm getting the timestamp relative to my computer's timezone. (GMT+9). So my epoch is the 9th hour of 1970-01-01. Which is not what I need. I need the GMT+0 UTC timestamp.
In this scenario, I'd get 1541948400
and 1542121199
, start and end respectively; where I should be getting 1541980800
and 1542153599
.
Tasukete kudasai
javascript date timestamp epoch
javascript date timestamp epoch
edited Nov 13 '18 at 4:47
Abana Clara
asked Nov 13 '18 at 2:46
Abana ClaraAbana Clara
1,561819
1,561819
1
" I want to convert it to timestamp while ignoring the client computer's current timezone" 👈 timestamps are timezone agnostic. They reflect the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z
– Phil
Nov 13 '18 at 2:53
@Phil I don't know how to properly phrase it but I get a different timestamp on this method, which is a very simple algorithm. When I convert the timestamp that I get in this method, it's always 9 hours ahead of UTC
– Abana Clara
Nov 13 '18 at 2:56
add a comment |
1
" I want to convert it to timestamp while ignoring the client computer's current timezone" 👈 timestamps are timezone agnostic. They reflect the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z
– Phil
Nov 13 '18 at 2:53
@Phil I don't know how to properly phrase it but I get a different timestamp on this method, which is a very simple algorithm. When I convert the timestamp that I get in this method, it's always 9 hours ahead of UTC
– Abana Clara
Nov 13 '18 at 2:56
1
1
" I want to convert it to timestamp while ignoring the client computer's current timezone" 👈 timestamps are timezone agnostic. They reflect the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z
– Phil
Nov 13 '18 at 2:53
" I want to convert it to timestamp while ignoring the client computer's current timezone" 👈 timestamps are timezone agnostic. They reflect the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z
– Phil
Nov 13 '18 at 2:53
@Phil I don't know how to properly phrase it but I get a different timestamp on this method, which is a very simple algorithm. When I convert the timestamp that I get in this method, it's always 9 hours ahead of UTC
– Abana Clara
Nov 13 '18 at 2:56
@Phil I don't know how to properly phrase it but I get a different timestamp on this method, which is a very simple algorithm. When I convert the timestamp that I get in this method, it's always 9 hours ahead of UTC
– Abana Clara
Nov 13 '18 at 2:56
add a comment |
1 Answer
1
active
oldest
votes
You have two options here...
Use
Date.UTC
to construct timestamps in UTCconst startDate = Date.UTC(start[0], start[1] - 1, start[2]) // a timestamp
const endDate = Date.UTC(end[0], end[1] - 1, end[2], 23, 59, 59) // a timestampNote:
Date.UTC()
produces a timestamp in milliseconds, not aDate
instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.Use your existing date strings which adhere to the ISO 8601 standard as the sole argument to the
Date
constructor.This benefits from this particular nuance...
Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
const startDate = new Date(sparams)
const endDate = new Date(eparams)Parsing ISO 8601 is supposedly supported in all decent browsers and IE from v9. Since this relies on a particular "feature" that may or may not be implemented in a client, there is an element of risk to this method.
For your end date, if parsing you can easily append a time and zone portion to the date string rather than manipulate the date object with hour, minute and second values. For example
const endDate = new Date(`$eparamsT23:59:59Z`)
alternatively, use Date.prototype.setUTCHours()
...
const endDate = new Date(eparams)
endDate.setUTCHours(23, 59, 59)
1
@AbanaClara from memory, strings in ISO 8601 format work fine in IE
– Phil
Nov 13 '18 at 3:00
2
I would be very hesitant to ever recommend using the built-in parser. Manually parsing ISO dates is 2 lines of code (or 1 if you want to get funky) and for that you get certainty vs. maybe… maybe not…
– RobG
Nov 13 '18 at 3:24
1
@RobG you mean you don't trustnew Date(someISO8601DateString)
? I've certainly been burnt by IE and non-ISO strings but never encountered a problem when the strings are formatted correctly
– Phil
Nov 13 '18 at 3:25
2
@Phil—not in a general web application where the device may be anything. I just think the risk mitigation is trivial. Also, parsing YYYY-MM-DD as UTC often confuses whereas parseAsLocal() and parseAsUTC make things clearer. ;-)
– RobG
Nov 13 '18 at 3:28
2
@RobG that's a very fair call. Glad I put both examples in then 🙂
– Phil
Nov 13 '18 at 3:31
|
show 9 more comments
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%2f53273046%2fget-current-timestamp-from-yyyy-mm-dd-hhmmss-using-utc-gmt0-as-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
You have two options here...
Use
Date.UTC
to construct timestamps in UTCconst startDate = Date.UTC(start[0], start[1] - 1, start[2]) // a timestamp
const endDate = Date.UTC(end[0], end[1] - 1, end[2], 23, 59, 59) // a timestampNote:
Date.UTC()
produces a timestamp in milliseconds, not aDate
instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.Use your existing date strings which adhere to the ISO 8601 standard as the sole argument to the
Date
constructor.This benefits from this particular nuance...
Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
const startDate = new Date(sparams)
const endDate = new Date(eparams)Parsing ISO 8601 is supposedly supported in all decent browsers and IE from v9. Since this relies on a particular "feature" that may or may not be implemented in a client, there is an element of risk to this method.
For your end date, if parsing you can easily append a time and zone portion to the date string rather than manipulate the date object with hour, minute and second values. For example
const endDate = new Date(`$eparamsT23:59:59Z`)
alternatively, use Date.prototype.setUTCHours()
...
const endDate = new Date(eparams)
endDate.setUTCHours(23, 59, 59)
1
@AbanaClara from memory, strings in ISO 8601 format work fine in IE
– Phil
Nov 13 '18 at 3:00
2
I would be very hesitant to ever recommend using the built-in parser. Manually parsing ISO dates is 2 lines of code (or 1 if you want to get funky) and for that you get certainty vs. maybe… maybe not…
– RobG
Nov 13 '18 at 3:24
1
@RobG you mean you don't trustnew Date(someISO8601DateString)
? I've certainly been burnt by IE and non-ISO strings but never encountered a problem when the strings are formatted correctly
– Phil
Nov 13 '18 at 3:25
2
@Phil—not in a general web application where the device may be anything. I just think the risk mitigation is trivial. Also, parsing YYYY-MM-DD as UTC often confuses whereas parseAsLocal() and parseAsUTC make things clearer. ;-)
– RobG
Nov 13 '18 at 3:28
2
@RobG that's a very fair call. Glad I put both examples in then 🙂
– Phil
Nov 13 '18 at 3:31
|
show 9 more comments
You have two options here...
Use
Date.UTC
to construct timestamps in UTCconst startDate = Date.UTC(start[0], start[1] - 1, start[2]) // a timestamp
const endDate = Date.UTC(end[0], end[1] - 1, end[2], 23, 59, 59) // a timestampNote:
Date.UTC()
produces a timestamp in milliseconds, not aDate
instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.Use your existing date strings which adhere to the ISO 8601 standard as the sole argument to the
Date
constructor.This benefits from this particular nuance...
Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
const startDate = new Date(sparams)
const endDate = new Date(eparams)Parsing ISO 8601 is supposedly supported in all decent browsers and IE from v9. Since this relies on a particular "feature" that may or may not be implemented in a client, there is an element of risk to this method.
For your end date, if parsing you can easily append a time and zone portion to the date string rather than manipulate the date object with hour, minute and second values. For example
const endDate = new Date(`$eparamsT23:59:59Z`)
alternatively, use Date.prototype.setUTCHours()
...
const endDate = new Date(eparams)
endDate.setUTCHours(23, 59, 59)
1
@AbanaClara from memory, strings in ISO 8601 format work fine in IE
– Phil
Nov 13 '18 at 3:00
2
I would be very hesitant to ever recommend using the built-in parser. Manually parsing ISO dates is 2 lines of code (or 1 if you want to get funky) and for that you get certainty vs. maybe… maybe not…
– RobG
Nov 13 '18 at 3:24
1
@RobG you mean you don't trustnew Date(someISO8601DateString)
? I've certainly been burnt by IE and non-ISO strings but never encountered a problem when the strings are formatted correctly
– Phil
Nov 13 '18 at 3:25
2
@Phil—not in a general web application where the device may be anything. I just think the risk mitigation is trivial. Also, parsing YYYY-MM-DD as UTC often confuses whereas parseAsLocal() and parseAsUTC make things clearer. ;-)
– RobG
Nov 13 '18 at 3:28
2
@RobG that's a very fair call. Glad I put both examples in then 🙂
– Phil
Nov 13 '18 at 3:31
|
show 9 more comments
You have two options here...
Use
Date.UTC
to construct timestamps in UTCconst startDate = Date.UTC(start[0], start[1] - 1, start[2]) // a timestamp
const endDate = Date.UTC(end[0], end[1] - 1, end[2], 23, 59, 59) // a timestampNote:
Date.UTC()
produces a timestamp in milliseconds, not aDate
instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.Use your existing date strings which adhere to the ISO 8601 standard as the sole argument to the
Date
constructor.This benefits from this particular nuance...
Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
const startDate = new Date(sparams)
const endDate = new Date(eparams)Parsing ISO 8601 is supposedly supported in all decent browsers and IE from v9. Since this relies on a particular "feature" that may or may not be implemented in a client, there is an element of risk to this method.
For your end date, if parsing you can easily append a time and zone portion to the date string rather than manipulate the date object with hour, minute and second values. For example
const endDate = new Date(`$eparamsT23:59:59Z`)
alternatively, use Date.prototype.setUTCHours()
...
const endDate = new Date(eparams)
endDate.setUTCHours(23, 59, 59)
You have two options here...
Use
Date.UTC
to construct timestamps in UTCconst startDate = Date.UTC(start[0], start[1] - 1, start[2]) // a timestamp
const endDate = Date.UTC(end[0], end[1] - 1, end[2], 23, 59, 59) // a timestampNote:
Date.UTC()
produces a timestamp in milliseconds, not aDate
instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.Use your existing date strings which adhere to the ISO 8601 standard as the sole argument to the
Date
constructor.This benefits from this particular nuance...
Support for ISO 8601 formats differs in that date-only strings (e.g. "1970-01-01") are treated as UTC, not local.
const startDate = new Date(sparams)
const endDate = new Date(eparams)Parsing ISO 8601 is supposedly supported in all decent browsers and IE from v9. Since this relies on a particular "feature" that may or may not be implemented in a client, there is an element of risk to this method.
For your end date, if parsing you can easily append a time and zone portion to the date string rather than manipulate the date object with hour, minute and second values. For example
const endDate = new Date(`$eparamsT23:59:59Z`)
alternatively, use Date.prototype.setUTCHours()
...
const endDate = new Date(eparams)
endDate.setUTCHours(23, 59, 59)
edited Nov 13 '18 at 3:45
Abana Clara
1,561819
1,561819
answered Nov 13 '18 at 2:58
PhilPhil
96.2k11136156
96.2k11136156
1
@AbanaClara from memory, strings in ISO 8601 format work fine in IE
– Phil
Nov 13 '18 at 3:00
2
I would be very hesitant to ever recommend using the built-in parser. Manually parsing ISO dates is 2 lines of code (or 1 if you want to get funky) and for that you get certainty vs. maybe… maybe not…
– RobG
Nov 13 '18 at 3:24
1
@RobG you mean you don't trustnew Date(someISO8601DateString)
? I've certainly been burnt by IE and non-ISO strings but never encountered a problem when the strings are formatted correctly
– Phil
Nov 13 '18 at 3:25
2
@Phil—not in a general web application where the device may be anything. I just think the risk mitigation is trivial. Also, parsing YYYY-MM-DD as UTC often confuses whereas parseAsLocal() and parseAsUTC make things clearer. ;-)
– RobG
Nov 13 '18 at 3:28
2
@RobG that's a very fair call. Glad I put both examples in then 🙂
– Phil
Nov 13 '18 at 3:31
|
show 9 more comments
1
@AbanaClara from memory, strings in ISO 8601 format work fine in IE
– Phil
Nov 13 '18 at 3:00
2
I would be very hesitant to ever recommend using the built-in parser. Manually parsing ISO dates is 2 lines of code (or 1 if you want to get funky) and for that you get certainty vs. maybe… maybe not…
– RobG
Nov 13 '18 at 3:24
1
@RobG you mean you don't trustnew Date(someISO8601DateString)
? I've certainly been burnt by IE and non-ISO strings but never encountered a problem when the strings are formatted correctly
– Phil
Nov 13 '18 at 3:25
2
@Phil—not in a general web application where the device may be anything. I just think the risk mitigation is trivial. Also, parsing YYYY-MM-DD as UTC often confuses whereas parseAsLocal() and parseAsUTC make things clearer. ;-)
– RobG
Nov 13 '18 at 3:28
2
@RobG that's a very fair call. Glad I put both examples in then 🙂
– Phil
Nov 13 '18 at 3:31
1
1
@AbanaClara from memory, strings in ISO 8601 format work fine in IE
– Phil
Nov 13 '18 at 3:00
@AbanaClara from memory, strings in ISO 8601 format work fine in IE
– Phil
Nov 13 '18 at 3:00
2
2
I would be very hesitant to ever recommend using the built-in parser. Manually parsing ISO dates is 2 lines of code (or 1 if you want to get funky) and for that you get certainty vs. maybe… maybe not…
– RobG
Nov 13 '18 at 3:24
I would be very hesitant to ever recommend using the built-in parser. Manually parsing ISO dates is 2 lines of code (or 1 if you want to get funky) and for that you get certainty vs. maybe… maybe not…
– RobG
Nov 13 '18 at 3:24
1
1
@RobG you mean you don't trust
new Date(someISO8601DateString)
? I've certainly been burnt by IE and non-ISO strings but never encountered a problem when the strings are formatted correctly– Phil
Nov 13 '18 at 3:25
@RobG you mean you don't trust
new Date(someISO8601DateString)
? I've certainly been burnt by IE and non-ISO strings but never encountered a problem when the strings are formatted correctly– Phil
Nov 13 '18 at 3:25
2
2
@Phil—not in a general web application where the device may be anything. I just think the risk mitigation is trivial. Also, parsing YYYY-MM-DD as UTC often confuses whereas parseAsLocal() and parseAsUTC make things clearer. ;-)
– RobG
Nov 13 '18 at 3:28
@Phil—not in a general web application where the device may be anything. I just think the risk mitigation is trivial. Also, parsing YYYY-MM-DD as UTC often confuses whereas parseAsLocal() and parseAsUTC make things clearer. ;-)
– RobG
Nov 13 '18 at 3:28
2
2
@RobG that's a very fair call. Glad I put both examples in then 🙂
– Phil
Nov 13 '18 at 3:31
@RobG that's a very fair call. Glad I put both examples in then 🙂
– Phil
Nov 13 '18 at 3:31
|
show 9 more comments
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%2f53273046%2fget-current-timestamp-from-yyyy-mm-dd-hhmmss-using-utc-gmt0-as-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
1
" I want to convert it to timestamp while ignoring the client computer's current timezone" 👈 timestamps are timezone agnostic. They reflect the number of seconds (or milliseconds) since 1970-01-01T00:00:00Z
– Phil
Nov 13 '18 at 2:53
@Phil I don't know how to properly phrase it but I get a different timestamp on this method, which is a very simple algorithm. When I convert the timestamp that I get in this method, it's always 9 hours ahead of UTC
– Abana Clara
Nov 13 '18 at 2:56