Get current timestamp from yyyy-mm-dd hh:mm:ss using UTC/GMT+0 as epoch










2














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










share|improve this question



















  • 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
















2














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










share|improve this question



















  • 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














2












2








2







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










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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













  • 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













1 Answer
1






active

oldest

votes


















2














You have two options here...




  1. Use Date.UTC to construct timestamps in UTC



    const 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 timestamp


    Note: Date.UTC() produces a timestamp in milliseconds, not a Date instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.




  2. 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)





share|improve this answer


















  • 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 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




    @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










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%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









2














You have two options here...




  1. Use Date.UTC to construct timestamps in UTC



    const 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 timestamp


    Note: Date.UTC() produces a timestamp in milliseconds, not a Date instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.




  2. 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)





share|improve this answer


















  • 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 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




    @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















2














You have two options here...




  1. Use Date.UTC to construct timestamps in UTC



    const 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 timestamp


    Note: Date.UTC() produces a timestamp in milliseconds, not a Date instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.




  2. 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)





share|improve this answer


















  • 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 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




    @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













2












2








2






You have two options here...




  1. Use Date.UTC to construct timestamps in UTC



    const 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 timestamp


    Note: Date.UTC() produces a timestamp in milliseconds, not a Date instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.




  2. 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)





share|improve this answer














You have two options here...




  1. Use Date.UTC to construct timestamps in UTC



    const 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 timestamp


    Note: Date.UTC() produces a timestamp in milliseconds, not a Date instance. Since you're able to set the hours, minutes and seconds as above, you no longer need to manipulate those.




  2. 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)






share|improve this answer














share|improve this answer



share|improve this answer








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 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




    @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




    @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 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




    @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

















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%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





















































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







這個網誌中的熱門文章

How to read a connectionString WITH PROVIDER in .NET Core?

In R, how to develop a multiplot heatmap.2 figure showing key labels successfully

Museum of Modern and Contemporary Art of Trento and Rovereto