refactor date, timestamp and datetime data types handling #257

darknos · 2017-04-09T22:25:02Z

This is a continue of #170.

I propose more correct way (from my point of view) of handling DATE, TIMESTAMP and DATETIME types.

Prevent double converting of date strings received from mysql server to js Date object using dateStrings: true setting for mysql connection.
Add support for timezone settings for cases when MysqlServer timezone is different from local one.
Add different handling of DATETIME and TIMESTAMP types as described in mysql documentation

MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions. The current time zone is available as the value of the time_zone system variable.

Correct way of handling DATE type
Ability to work with DATE, TIMESTAMP and DATETIME fields without any conversion (type:String instead of type:Date in property definition)
Added unit tests to check all possible cases, different time zones, and date types.

Related issues

#170

Checklist

New tests added or existing tests modified to cover all changes
Code conforms with the style
guide

connected to https://github.com/strongloop-internal/scrum-apex/issues/173

darknos · 2017-04-09T22:27:26Z

ping @ssh24

slnode · 2017-04-09T22:35:43Z

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

slnode · 2017-04-09T22:35:48Z

Can one of the admins verify this patch?

slnode · 2017-04-09T22:35:49Z

Can one of the admins verify this patch?

slnode · 2017-04-09T22:35:49Z

Can one of the admins verify this patch?

ssh24 · 2017-04-09T23:26:22Z

@slnode test please

ssh24 · 2017-04-09T23:38:50Z

test/datetypes.notz.test.js

+
+var localTZ = getTimeZone();
+
+describe('MySQL DATE, DATETTIME, TIMESTAMP types on server with local TZ', function() {


Please move these two test cases all under one test file. For example in ./test/datatypes.test.js/.

ssh24 · 2017-04-09T23:40:52Z

test/datetypes.notz.test.js

+      });
+  });
+
+  it('should create table', function(done) {


Don't have a test case for it. And instead of creating a table like this, create a loopback model directly and automigrate the model to the database. More on automigrate here.

I create table via SQL to have a test field with DEFAULT CURRENT_TIMESTAMP:
timestampDefaultField timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,.

for this test case:

it('timestampField shoud equal DEFAULT CURRENT_TIMESTAMP field', function(done) { DateModel.findOne({where: {id: 1}}, function(err, found) { assert.ok(!err); assert.equal(found.timestampField.toISOString(), found.timestampDefaultField.toISOString()); done(); }); });

It is needed to be sure that time set on server side is the same as time we pass from new Date();

I know how to use auto migration but don't know how to create field with such defaults. I can do auto migrate and then query ALTER TABLE CHANGE timestampDefaultField timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP. Is it acceptable?

and, sure, I'll move it to setup section instead of test case

ssh24 · 2017-04-09T23:42:51Z

test/datetypes.notz.test.js

+  });
+});
+
+function setup(done) {


Don't need any of these setup AFAIK. All the models/tables should be on the default database the test runs against.

I unified setup procedures for both test cases

darknos · 2017-04-10T13:06:15Z

Done. @ssh24, please review.

ssh24 · 2017-04-10T15:32:55Z

@darknos Looks like loopback does not support timestamp and datetime as a data type as of yet. Look at the supported data types here. Those are specific to mysql and I am not sure if it is in our roadmap.

@raymondfeng Could you correct me if I am wrong?

darknos · 2017-04-10T20:02:22Z

Js Date type is mapped to mysql datetime, date or timestamp.

I use loopack on tens of clients project and in most cases in their databases were these three types. loopback has to support all of them.

ssh24 · 2017-04-10T20:10:31Z

test/date_types.test.js

+    id: {type: Number, id: 1, generated: true},
+    datetimeField: {type: Date, dataType: 'datetime', null: false},
+    timestampField: {type: Date, dataType: 'timestamp', null: false},
+    timestampDefaultField: {type: Date, dataType: 'timestamp', null: false},


@darknos You would need to change the dataType in that case here then. LoopBack does not support timestamp as an official data type. We support date which is the JavaScript date object. More info on docs.

~~Same for datetime as a data type.~~

Sorry totally ignore my comment. I thought for some reason you were invoking the loopback model with dataType timestamp.

https://github.com/strongloop/loopback-connector-mysql/blob/master/README.md#loopback-to-mysql-types

Type mappings:
LoopBack to MySQL types
Date -> DATETIME

MySQL to LoopBack types
DATE,TIMESTAMP,DATETIME -> Date

I just want to make this mapping correct. Try my simple and clear test cases with current version of connector to see what is wrong.

ssh24

@darknos Code LGTM. I did some small cleanups. Please fix the rest of the code with the suggested changes. Make sure to pull the latest before committing any changes.

ssh24 · 2017-04-11T02:30:24Z

test/date_types.test.js

+      },
+    }, function(err, found) {
+      assert.ok(!err);
+      assert.ok(found);


Could assert for something more than just found?

assert.equal(found.id, 1); should be enough - we have to be sure that param of each type is working and found proper recored.

ssh24 · 2017-04-11T02:30:37Z

test/date_types.test.js

+      },
+    }, function(err, found) {
+      assert.ok(!err);
+      assert.ok(found);


Same here. Assert more than just found

ssh24 · 2017-04-11T02:30:52Z

test/date_types.test.js

+      },
+    }, function(err, found) {
+      assert.ok(!err);
+      assert.ok(found);


Same here. Assert more than just found

ssh24 · 2017-04-11T02:32:56Z

lib/mysql.js

+    } else if (prop.dataType == 'timestamp' || (prop.mysql && prop.mysql.dataType == 'timestamp')) {
+      var tz = this.client.config.connectionConfig.timezone;
+      return dateToMysql(val, tz);
+    } else {


Remove the else. Just return dateToMysql(val); is good.

ssh24 · 2017-04-11T02:33:29Z

lib/mysql.js

+    }
+
+    var m = tz.match(/([\+\-\s])(\d\d):?(\d\d)?/);
+    if (m) {


One liner for this should be fine: if (m) return (m[1] == '-' ? -1 : 1) * (parseInt(m[2], 10) + ((m[3] ? parseInt(m[3], 10) : 0) / 60)) * 60;

ssh24 · 2017-04-11T02:34:16Z

lib/mysql.js

+  } else {
+    tz = convertTimezone(tz);
+
+    if (tz !== false && tz !== 0) {


Change this to: if (tz !== false && tz !== 0) dt.setTime(dt.getTime() + (tz * 60000));

darknos · 2017-04-11T12:19:22Z

Done. @ssh24 please review

ssh24 · 2017-04-11T17:53:20Z

test/date_types.test.js

+    });
+  });
+
+  it('should find model instance by date field passing string', function(done) {


@darknos Test is failing locally for this. Why is this a valid test case to test for a dateField of type string when it expects a Date object?

All "where" parameters are passed normalize function of "juggler".
https://github.com/strongloop/loopback-datasource-juggler/blob/master/lib/dao.js#L1146
If property is one of type Date it does new Date(arg)
https://github.com/strongloop/loopback-datasource-juggler/blob/master/lib/dao.js#L1540

for DATE type test case will pass for timezones like my one (+xxxx):
"2016-12-22" -> "Thu Dec 22 2016 02:00:00 GMT+0200 (EET)"
but
will fail for (-xxxx) timezones:
"2016-12-22" -> "Thu Dec 21 2016 22:00:00 GMT-0200"

I'm going to remove this test case but I'd suggest to mean it in documentation.

It is a question how to pass where parameter to DATE field in different timezone via REST interface.

f.e. server is in GMT-6000 timezone and client is in GMT+2000 timezone. on client side we do:

  var filter = {where:{dateFiled:new Date(2016,11,22)}};  

it will pass as {"where":{"dateFiled":"2016-12-21T22:00:00.000Z"}}

and dao will convert it to date Wed Dec 21 2016 16:00:00 GMT-0600 (CST) and pass to SQL as 2016-12-21 and we got wrong result. :(

ssh24 · 2017-04-11T17:53:42Z

test/date_types.test.js

@@ -202,6 +217,18 @@ describe('MySQL DATE, DATETTIME, TIMESTAMP types on server with non local TZ (+0
    });
  });

+  it('should find model instance by date field passing string', function(done) {


Same reason here. Test is failing locally for this. Why is this a valid test case to test for a dateField of type string when it expects a Date object?

darknos · 2017-04-11T19:49:23Z

It is a question how to pass where parameter to DATE field in different timezones via REST interface.

f.e. server is in GMT-6000 timezone and client is in GMT+2000 timezone. on client side we do:

  var filter = {where:{dateFiled:new Date(2016,11,22)}};

it will pass via HTTP as {"where":{"dateFiled":"2016-12-21T22:00:00.000Z"}}
and dao will convert it to date Wed Dec 21 2016 16:00:00 GMT-0600 (CST) and pass to SQL as 2016-12-21 and we get wrong result. :(

ssh24 · 2017-04-11T20:38:26Z

@darknos Not sure what you mean

it will pass via HTTP as {"where":{"dateFiled":"2016-12-21T22:00:00.000Z"}}
and dao will convert it to date Wed Dec 21 2016 16:00:00 GMT-0600 (CST) and pass to SQL as 2016-12-21 and we get wrong result

What is the wrong result?

bbito · 2017-04-11T20:50:07Z

I wish I had time right now to really look at the implications of this PR, but unfortunately I do not right now. I do want to comment that I'm concerned about forcing the mysql config: dateStrings: true since users could previously assume that mysql config settings in their datasources.json would be passed to the underlying mysql module. EDIT 20170418 - fix link:
https://github.com/strongloop/loopback-connector-mysql/blob/master/lib/mysql.js#L140
I also want to point to an issue I was involved with that I feel is closely related: https://github.com/strongloop/loopback-connector-mysql/issues/149
That issue identifies that this connector currently does not properly handle MySQL timezone settings and in fact currently stores and retrieves UTC. A fix is a breaking change because datetime comparisons between data created before and after such a fix will be incorrect because of the long-standing behavior of storing UTC despite the docs stating that the default is 'local'.

darknos · 2017-04-11T21:01:34Z

@darknos Not sure what you mean

it will pass via HTTP as {"where":{"dateFiled":"2016-12-21T22:00:00.000Z"}}
and dao will convert it to date Wed Dec 21 2016 16:00:00 GMT-0600 (CST) and pass to SQL as 2016-12-21 and we get wrong result

What is the wrong result?

Pretend we have field dateField with value "2016-12-22" stored in database and I want to get records with this value. I'll do

var filter = {where:{dateFiled:new Date(2016,11,22)}};

but it will execute SQL select * from table where dateField = ' 2016-12-21'

If server is in +0200 timezone and I'll do

var filter = {where:{dateFiled:'20160-12-22'}};

the SQL will be select * from table where dateField = ' 2016-12-22'

If server is in -0500 timezone
the SQL will be select * from table where dateField = ' 2016-12-21'

darknos · 2017-04-11T21:13:36Z

@bbito

That issue identifies that this connector currently does not properly handle MySQL timezone settings and in fact currently stores and retrieves UTC. A fix is a breaking change because datetime comparisons between data created before and after such a fix will be incorrect because of the long-standing behavior of storing UTC despite the docs stating that the default is 'local'.

this PR fixes timezone handling and makes difference between handling DATETIME and TIMESTAMP as described in MySQL documentation.

I found only one way to fix it - make only one conversion from mysql strings to js Date object and do it in the loopback connector but not on node-mysql side.

Probably there are another ways to fix it but I'd ask to keep test/date_types.test.js I made for it and even extend it if you have any ideas about other test cases. I guess you can get ideas of new test cases from #149

bbito · 2017-04-11T21:28:31Z

@darknos

makes difference between handling DATETIME and TIMESTAMP as described in MySQL documentation.

I don't think there should be a difference in the way this connector handles DATETIME vs TIMESTAMP:

#149 (comment)

ssh24 · 2017-04-11T23:10:05Z

Still not sure what is the problem.

Pretend we have field dateField with value "2016-12-22" stored in database and I want to get records with this value. I'll do

var filter = {where:{dateFiled:new Date(2016,11,22)}};

but it will execute SQL select * from table where dateField = ' 2016-12-21'

Why should it execute SQL with dateField's date equal to 21? I am assuming the server is in GMT, and you are accessing it from somewhere GMT-x timezone?

darknos · 2017-04-12T06:01:16Z

@bbito

makes difference between handling DATETIME and TIMESTAMP as described in MySQL documentation.

I don't think there should be a difference in the way this connector handles DATETIME vs TIMESTAMP:
#149 (comment)

There is a simple way to see that the difference is present. It is described in my test cases.

add the same value to DATETIME and TIMESTAMP field
change @session.time_zone value
retrieve values and mysql will return different values for these fields

mysql> create table test (dt  datetime, ts timestamp);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into test values ('2017-04-11 14:38:07', '2017-04-11 14:38:07');
Query OK, 1 row affected (0.00 sec)

mysql> select * from test;
+---------------------+---------------------+
| dt                  | ts                  |
+---------------------+---------------------+
| 2017-04-11 14:38:07 | 2017-04-11 14:38:07 |
+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> set @@session.time_zone = '+05:30';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from test;
+---------------------+---------------------+
| dt                  | ts                  |
+---------------------+---------------------+
| 2017-04-11 14:38:07 | 2017-04-11 17:08:07 |
+---------------------+---------------------+
1 row in set (0.00 sec)

Just runt test/date_types.test.js with DEBUG=mysql to see mysql data packets.

darknos · 2017-04-12T06:15:19Z

Still not sure what is the problem.

Pretend we have field dateField with value "2016-12-22" stored in database and I want to get records with this value. I'll do
var filter = {where:{dateFiled:new Date(2016,11,22)}};  
but it will execute SQL select * from table where dateField = ' 2016-12-21'

Why should it execute SQL with dateField's date equal to 21? I am assuming the server is in GMT, and you are accessing it from somewhere GMT-x timezone?

in GMT+2 tz new Date(2016,11,22) will be converted to "2016-12-21T22:00:00.000Z"
when loopback receive rest route to find it will "normalize" where statement
https://github.com/strongloop/loopback-datasource-juggler/blob/master/lib/dao.js#L1146
https://github.com/strongloop/loopback-datasource-juggler/blob/master/lib/dao.js#L1540
if server is in GMT+0 - no problem. we'll get Wed Dec 22 2016 00:00:00 GMT and in loopback-connector-mysql, toColumnValue function will convert it to string 2016-12-22 and pass to mysql.
BUT if server is not in UTC. (f.e. GMT-05:00 like when you started "strings" test case on your side) it will convert "2016-12-21T22:00:00.000Z" to Wed Dec 21 2016 00:00:00 GMT and toColumnValue function will convert it to string 2016-12-21.

this is connected only to WHERE not to INSERT or UPDATE

this is not issue but I'd suggest to describe it as "notice" in documentation.

darknos · 2017-04-21T13:04:21Z

@DaGaMs

We work with date time as below and I expect such behavior.

let date = new Date();
let dateString = date.toISOString();
DateModel.create({
     id: 1.
     datetimeField: date,
}, function(err, res) {
    DateModel.findOne({where:{dateField: date}, function(err, result) {
      //result.id == 1;
   }     
   //or
    DateModel.findOne({where:{dateField: dateString}, function(err, result) {
      //result.id == 1;
   }     
}

where do you suggest to specify explicit timezone?

darknos · 2017-04-21T13:10:15Z

I'm not sure that understand 'bizarre behavior'. In my TZ:

> console.log(new Date("2016-01-03 00:08:06"))
Sun Jan 03 2016 00:08:06 GMT+0200 (EET)
> console.log(new Date("2016-10-23 00:08:06"))
Sun Oct 23 2016 00:08:06 GMT+0300 (EEST)

one hour difference is Daylight Saving Time difference

> console.log(new Date("2016-01-03 00:08:06").toISOString())
2016-01-02T22:08:06.000Z
> console.log(new Date("2016-10-23 00:08:06").toISOString())
2016-10-22T21:08:06.000Z

DaGaMs · 2017-04-21T13:10:17Z

I suggest that if you initialise a MySQL datasource with {timezone: "+04:00"}, then all DATETIME columns in the datasource should be assumed to be in that timezone. So, if I did a raw SELECT and got a value of 2016-04-12 11:23:00, I would assume that this is the same as 2016-04-12 07:23:00 UTC.

darknos · 2017-04-21T13:21:21Z

@DaGaMs So, do you just suggest to change this

//if datatype is timestamp and zimezone is not local - convert to proper timezone
if (tz !== 'local' && (prop.dataType == 'timestamp' || (prop.mysql && prop.mysql.dataType == 'timestamp'))) {
        dateString += ' ' + tz;
}

to this

//if   timezone is not local - convert to proper timezone
if (tz !== 'local') {
        dateString += ' ' + tz;
}

?

DaGaMs · 2017-04-21T13:25:32Z

yes. And correspondingly also make sure that whatever gets written to the db is converted to the tz of the connection

darknos · 2017-04-21T13:30:55Z

sure:

 } else if (prop.dataType == 'timestamp' || (prop.mysql && prop.mysql.dataType == 'timestamp')) {
    var tz = this.client.config.connectionConfig.timezone;
    return dateToMysql(val, tz);
}
return dateToMysql(val);

to

    return dateToMysql(val, this.client.config.connectionConfig.timezone);

darknos · 2017-04-21T13:46:34Z

@DaGaMs
iPublisherUA@fdda36d

all tests are passed.

DaGaMs · 2017-04-21T17:05:24Z

I had test failures with your branch, strangely. Here is a branch where all tests are passing for me:

DaGaMs@f947c1a

bbito · 2017-04-21T18:35:40Z

Should discussion about this (loopback-connector-mysql date / time zone issues) continue here or at #149?

superkhau · 2017-04-21T22:36:31Z

I think @darknos should open up a PR with the legacyBehaviour flag mentioned above and we can reference this issue and #149 to that PR for the fixup and release ASAP so you and @DaGaMs can get their fixes right away with an immediate publish.

cc @ssh24 @kjdelisle

bbito · 2017-04-21T23:33:59Z

Hey @superkhau , I don't have a 'fix' ready to go. My feeling is that this (#257) goes in the opposite direction from what was discussed at #149 where I was suggesting removing all the code converting dates to UTC and just handing off and receiving js Date objects to/from the underlying mysql module. I do have a fork with that stuff removed that works fine in my limited testing, but I don't have any legacy fallback or the docs for upgrading. This (#257) goes completely the other way and forces the underlying module to produce String values for all date types.

superkhau · 2017-04-22T01:10:59Z

@bbito I hear your concern. Maybe the simplest route is to revert #257 and continue the discussion at #149.

My feeling is we need to do:

Add a compatibility flag allowing users to opt into old behaviour - this will simplify upgrade from the current version of the connector
Provide documentation on how to upgrade data stored in MySQL from the UTC format to the new format, to allow users to eventually switch off the compat flag.

as suggested by @bajtos at #149

Then in a subsequent PR (after continuing some discussion at #149):

Change the default behaviour of this connector to match the suggestions in the MySQL documentation
Release the changes as a new major version of the connector

Thoughts?

bbito · 2017-04-22T01:31:51Z

@superkhau That sound best to me! I think what we came up with at #149 was a solid plan.

DaGaMs · 2017-04-22T08:16:33Z

@superkhau I'm pretty sure that with the updated code (after @darknos and my discussion yesterday) the "compatibility setting" would simply be to make "timezone": "+00:00" the default for all connections. Then all dates going in and out of the db would be interpreted as UTC, AFAICS.

DaGaMs · 2017-04-22T08:18:58Z

@bbito I'm not sure I agree any more with the idea of leaving all date casting to javascript. In that case, a change in the timezone setting of the server that the loopback instance runs on would change the interpretation of the data. I prefer the more "explicit" setting in the datasource.json file, so it's totally clear that all dates that go in and come out of the database are in a specific timezone (and UTC is a very sensible default ;-) )

darknos · 2017-04-22T11:02:26Z

@superkhau, @ssh24 , @DaGaMs I added new PR: #265 and I'll wait for your decision.

ssh24 · 2017-04-22T13:47:03Z

Following up on the discussion between @darknos and @DaGaMs, I am okay with the idea of enabling a flag to allow the previous behavior and the new behavior. If the fixes on #265 are sensible, this PR does not need to be reverted.

bbito · 2017-04-24T14:26:07Z

@DaGaMs

I prefer the more "explicit" setting in the datasource.json file

I completely agree and this was the crux of #149 (comment). Any fix must honor "timezone":"..." in datasources.json unless the proposed legacy compatibility flag is set in which case the module should continue to ignore the timezone set in datasources. I currently have legacy compatibility default to true - so one needs to opt-in to new behavior, but I'm fine with either true or false for default.

…)" This reverts commit f2f0dac.

ssh24 · 2017-04-24T20:18:18Z

Reverting this PR as it is a breaking change for other users. Please follow #149 as we try to come up with a cleaner solution.

darknos · 2017-04-24T20:33:22Z

got it. after all discussions I see that the best way is to keep own fork of the connector. :(

Resolve conflicts following revert of loopbackio#257 via loopbackio#266

* Tests for datetime types (Kevin Delisle) * Add new type DateString to fromColumnValue (Buck Bito) * Remove String manipulations of Date objects (Buck Bito) * Properties with mysql custom "columnName" don't get autoupdated (#273) (Sergey Nosenko) * Revert PR #257 (#266) (Sakib Hasan) * Fix async.each in migration (#262) (Benjamin Schuster-Boeckler) * refactor date, timestamp and datetime data types handling (#257) (Sergey Nosenko) * Fix too many connection error (#261) (Sakib Hasan)

darknos mentioned this pull request Apr 9, 2017

fix and refactoring timestamp and datetime data types handling #170

Closed

ssh24 force-pushed the master branch 2 times, most recently from a118455 to 1bb8e05 Compare April 9, 2017 23:26

ssh24 suggested changes Apr 9, 2017

View reviewed changes

ssh24 force-pushed the master branch from 3066784 to 24e74e2 Compare April 10, 2017 14:46

ssh24 reviewed Apr 10, 2017

View reviewed changes

ssh24 reviewed Apr 11, 2017

View reviewed changes

ssh24 self-assigned this Apr 11, 2017

ssh24 force-pushed the master branch from 810bcd6 to 1380e6d Compare April 11, 2017 20:41

darknos mentioned this pull request Apr 22, 2017

legacyDateTypeProcessing flag for datetime processing #265

Closed

ssh24 pushed a commit that referenced this pull request Apr 24, 2017

Revert "refactor date, timestamp and datetime data types handling (#257…

4baae83

…)" This reverts commit f2f0dac.

ssh24 mentioned this pull request Apr 24, 2017

Revert "refactor date, timestamp and datetime data types handling" #266

Merged

ssh24 pushed a commit that referenced this pull request Apr 24, 2017

Revert PR #257

f293e97

ssh24 pushed a commit that referenced this pull request Apr 24, 2017

Revert PR #257 (#266)

345492e

bbito added a commit to bbito/loopback-connector-mysql that referenced this pull request Apr 25, 2017

Merge remote-tracking branch 'upstream/master'

f7d1990

Resolve conflicts following revert of loopbackio#257 via loopbackio#266

bbito pushed a commit to bbito/loopback-connector-mysql that referenced this pull request Apr 25, 2017

Revert PR loopbackio#257 (loopbackio#266)

b1d3f11

darknos mentioned this pull request Apr 27, 2017

Remove String manipulations of Date objects #271

Merged

2 tasks

bajtos mentioned this pull request Sep 4, 2020

Setting a timezone other than UTC as default loopbackio/loopback-next#3430

Closed


		var localTZ = getTimeZone();

		describe('MySQL DATE, DATETTIME, TIMESTAMP types on server with local TZ', function() {

refactor date, timestamp and datetime data types handling #257

refactor date, timestamp and datetime data types handling #257

Conversation

darknos commented Apr 9, 2017 • edited by ssh24 Loading

Related issues

Checklist

darknos commented Apr 9, 2017

slnode commented Apr 9, 2017

slnode commented Apr 9, 2017

slnode commented Apr 9, 2017

slnode commented Apr 9, 2017

ssh24 commented Apr 9, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darknos commented Apr 10, 2017

ssh24 commented Apr 10, 2017

darknos commented Apr 10, 2017

ssh24 Apr 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ssh24 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darknos commented Apr 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darknos Apr 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darknos commented Apr 11, 2017

ssh24 commented Apr 11, 2017

bbito commented Apr 11, 2017 • edited Loading

darknos commented Apr 11, 2017 • edited Loading

darknos commented Apr 11, 2017

bbito commented Apr 11, 2017 • edited Loading

ssh24 commented Apr 11, 2017

darknos commented Apr 12, 2017

darknos commented Apr 12, 2017 • edited Loading

darknos commented Apr 21, 2017

darknos commented Apr 21, 2017

DaGaMs commented Apr 21, 2017

darknos commented Apr 21, 2017

DaGaMs commented Apr 21, 2017

darknos commented Apr 21, 2017

darknos commented Apr 21, 2017

DaGaMs commented Apr 21, 2017

bbito commented Apr 21, 2017

superkhau commented Apr 21, 2017

bbito commented Apr 21, 2017

superkhau commented Apr 22, 2017 • edited Loading

bbito commented Apr 22, 2017

DaGaMs commented Apr 22, 2017

DaGaMs commented Apr 22, 2017

darknos commented Apr 22, 2017

ssh24 commented Apr 22, 2017

bbito commented Apr 24, 2017

ssh24 commented Apr 24, 2017

darknos commented Apr 24, 2017

darknos commented Apr 9, 2017 •

edited by ssh24

Loading

ssh24 Apr 10, 2017 •

edited

Loading

darknos Apr 11, 2017 •

edited

Loading

bbito commented Apr 11, 2017 •

edited

Loading

darknos commented Apr 11, 2017 •

edited

Loading

bbito commented Apr 11, 2017 •

edited

Loading

darknos commented Apr 12, 2017 •

edited

Loading

superkhau commented Apr 22, 2017 •

edited

Loading