Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect result when inserting into DATE column when client timezone is ahead of UTC #154

Closed
stegus64 opened this issue Jul 31, 2019 · 2 comments
Labels

Comments

@stegus64
Copy link
Contributor

Issue description

The test SFDbDataReader.TestGetDate() fails when running on a client that is ahead of UTC (Such as UTC+1, Stockholm)

The reason is probably the following code in SFDataConverter:208

                        long millis = (long)((DateTime)srcVal).ToUniversalTime().Subtract(
                            UnixEpoch).TotalMilliseconds;

ToUniversalTime() will change the date by subtracting from midnight when the client is ahead of UTC.
This means the wrong value is inserted into the database.

Everything works correctly when the client is after UTC such as in America.

The call to ToUniversalTime() should simply be removed.

Configuration

Driver version: 1.0.12

Dotnet framework and version: .net standard 2.0

Client OS: Windows 10

stegus64 added a commit to stegus64/snowflake-connector-net that referenced this issue Aug 2, 2019
Note that this might cause backward compatibility problems. It is possible that someone has noted this problem and added compensating code in the client.
Note that this is only a problem for users where the client is after GMT such as Stockholm or Helsinki
stegus64 added a commit to stegus64/snowflake-connector-net that referenced this issue Aug 2, 2019
Fix for snowflakedb#154. Removed incorrect call to ToUniversalTime()
@stegus64 stegus64 mentioned this issue Aug 2, 2019
stegus64 added a commit to stegus64/snowflake-connector-net that referenced this issue Aug 6, 2019
stegus64 added a commit to stegus64/snowflake-connector-net that referenced this issue Aug 6, 2019
Note that this might cause backward compatibility problems. It is possible that someone has noted this problem and added compensating code in the client.
Note that this is only a problem for users where the client is after GMT such as Stockholm or Helsinki
@stegus64 stegus64 mentioned this issue Aug 15, 2019
@stegus64
Copy link
Contributor Author

@ChTimTsubasa Please remember that this issue has not been fixed. pr #156 should fix this, but that pr has been closed without merging.

ChTimTsubasa pushed a commit that referenced this issue Sep 3, 2019
ChTimTsubasa pushed a commit that referenced this issue Sep 3, 2019
Note that this might cause backward compatibility problems. It is possible that someone has noted this problem and added compensating code in the client.
Note that this is only a problem for users where the client is after GMT such as Stockholm or Helsinki
@ChTimTsubasa
Copy link
Contributor

Merged through #168

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants