Localtime is assumed to be UTC..

[deepgnly]

First of all I am based in 'Asia/Kolkata' timezone which is +530 from UTC
The value which I input in the DB looks like this -> 2017.12.24T21:32:59.103 317.5 . -> this is the localtime
When I query this value from the kdb console I get the above value back, which is correct.
However when I try to use this node adapter I get -> 2017.12-25 02:56:59.770.
The difference is exactly +530 from the local time.
When I use nodejs to get the local time it gives the right output. So my best guess is during transformation the timezone value is changed here

[michaelwittig]

Have you tried "2: think about running your Node.js process with TZ=UTC node ... to run in UTC timezone. q doesn't know timezones." ?

[deepgnly]

Yes I tried using TZ=UTC as well.The result is no different. I changed operating system and found that this error is only with Window 10 version, but other linux based OS it works perfectly fine.

[stanleyxu2005]

I'm new to this project. (still have zero programming experience on node-q).

It seems you want node-q or q to recognize datetime string smartly. But I think according to ISO8901, the string 2017.12.24T21:32:59.103 317.5 is neither a standard local timestamp nor a standard UTC time stamp. I don't know whether node-q is able to convert such data with a specified timestring format. I think momentjs is able to handle this.

I hope this clue can help you to find whether the problem is in node-q or in q.

[michaelwittig]

node-q does not parse strings. You have to provide a Date object instead.

@gullyy maybe you can share some code to demonstrate how you use the library to help you with this issue?

[deepgnly]

I tried to paste the code here,but the formatting really sucks ,therefore create the following gist.
https://gist.github.com/gullyy/f2abc40b35be6a5c6c2ed48e55c62531
I do the insertIntoTickTable and then nakedTableRead to read back the data. This returned back object contains the date as UTC instead of locatime. As of now I have solved this problem by futher parsing the data using offset/substracting the difference(IST-UTC) of the time between the two timezones, but would like to know what is causing this.

[michaelwittig]

In your example, the first datetime is 2017.12.19T11:56:02.544. Is this in UTC time?
If you look at the table using the q client, what do you see? also 2017.12.19T11:56:02.544 ?
If you retrieve the data with the nakedTableRead function, what do you get? 2017.12.19T11:56:02.544 ? Do you run node with TZ=UTC?

[deepgnly]

In your example, the first datetime is 2017.12.19T11:56:02.544. Is this in UTC time?
- No this localtime, which is IST.

If you look at the table using the q client, what do you see? also 2017.12.19T11:56:02.544 ?
- yes I get this result with q client. The input value is the output value as per any q client.

If you retrieve the data with the nakedTableRead function, what do you get? 2017.12.19T11:56:02.544 ?
-I get 2017.12.19 17:26:02.544 which is +330 minutes(IST-GMT difference).

Do you run node with TZ=UTC?
-_no I simply run using npm start, after this issue I am running with

process.env["TZ"] = "Asia/Kolkata"

but it doesnt change anything._

[michaelwittig]

I guess the problem is the following:

when you insert the data, you use a string which means that node-q does no parsing at all. the string is just transfered to q where it is interpreted as an UTC datetime. no conversion happens at all. But your datetime string is actually not in UTC. So the timestamp that q stored will be kind of wrong.

When you view the data with the q client, you will see the datetime as inserted, because q just displays the timestamp in UTC datetime format.

When you get the data back, Node.js converts the timestamp into a Date object. The timestamp in q is 2017.12.19T11:56:02.544 UTC and then Node.js converts it into your local timezone and windows / Node.js for windows does not care about the TZ env variable, e.g. nodejs/node#4230. That's why you end up with a wrong time.

1.I would change the input to UTC datetimes or
2. You can change the Windows system timezone, e.g. nodejs/node#4022

Let me know if this works.

[deepgnly]

Yes the options mentioned by you works..right now I am doing an extra parsing-substracting the minutes from the value received from the db. One question. In your option 1
If I still want to insert the local datetime but not in a string format, can I do so, using the node-q client? If yes how?

[michaelwittig]

you can do something like this (untested):

con.k("upsert", tableName, [[new Date("2017-12-19T11:56:02.544"), new Date("2017-12-19T11:56:02.544")], [410.0, 411.0]], function(err, res) {
	if (err) throw err;
	console.log("result", res); // 1
});

[deepgnly]

Great I will use this. Thanks a ton! Closing the issue