BigQuery Standard SQL returns different WEEK from timestamp
up vote
1
down vote
favorite
I am converting an old query from Legacy SQL to Standard SQL and noticed my report was off. I've traced it back to Legacy SQL and Standard SQL returning different weeks based off of a UNIX millisecond timestamp.
I was under the impression the Legacy SQL query was correct, but however, I'm curious to know the difference. It's not across all weeks, but enough to throw my report off significantly.
Here's an example:
#legacySQL
SELECT WEEK(MSEC_TO_TIMESTAMP(1470631859000)) AS sign_up_week;
Output: 33
#standardSQL
SELECT EXTRACT(WEEK FROM TIMESTAMP_MILLIS(1470631859000));
Output: 32
I've viewed the following documentation on the Legacy SQL reference:
WEEK(<timestamp>)
Returns the week of a TIMESTAMP data type as an integer between 1 and 53, inclusively.
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
And from the Standard SQL reference:
WEEK(<WEEKDAY>): Returns the week number of the date in the range [0, 53]. Weeks begin on WEEKDAY. Dates prior to the first WEEKDAY of the year are in week 0. Valid values for WEEKDAY are SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, and SATURDAY.
ISOWEEK: Returns the ISO 8601 week number of the date_expression. ISOWEEKs begin on Monday. Return values are in the range [1, 53]. The first ISOWEEK of each ISO year begins on the Monday before the first Thursday of the Gregorian calendar year.
How can I get my Standard SQL query to output the same week number as my Legacy SQL query? If not, which week number is correct? It does not appear I can get them to dovetail natively.
sql google-bigquery unix-timestamp standard-sql
add a comment |
up vote
1
down vote
favorite
I am converting an old query from Legacy SQL to Standard SQL and noticed my report was off. I've traced it back to Legacy SQL and Standard SQL returning different weeks based off of a UNIX millisecond timestamp.
I was under the impression the Legacy SQL query was correct, but however, I'm curious to know the difference. It's not across all weeks, but enough to throw my report off significantly.
Here's an example:
#legacySQL
SELECT WEEK(MSEC_TO_TIMESTAMP(1470631859000)) AS sign_up_week;
Output: 33
#standardSQL
SELECT EXTRACT(WEEK FROM TIMESTAMP_MILLIS(1470631859000));
Output: 32
I've viewed the following documentation on the Legacy SQL reference:
WEEK(<timestamp>)
Returns the week of a TIMESTAMP data type as an integer between 1 and 53, inclusively.
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
And from the Standard SQL reference:
WEEK(<WEEKDAY>): Returns the week number of the date in the range [0, 53]. Weeks begin on WEEKDAY. Dates prior to the first WEEKDAY of the year are in week 0. Valid values for WEEKDAY are SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, and SATURDAY.
ISOWEEK: Returns the ISO 8601 week number of the date_expression. ISOWEEKs begin on Monday. Return values are in the range [1, 53]. The first ISOWEEK of each ISO year begins on the Monday before the first Thursday of the Gregorian calendar year.
How can I get my Standard SQL query to output the same week number as my Legacy SQL query? If not, which week number is correct? It does not appear I can get them to dovetail natively.
sql google-bigquery unix-timestamp standard-sql
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am converting an old query from Legacy SQL to Standard SQL and noticed my report was off. I've traced it back to Legacy SQL and Standard SQL returning different weeks based off of a UNIX millisecond timestamp.
I was under the impression the Legacy SQL query was correct, but however, I'm curious to know the difference. It's not across all weeks, but enough to throw my report off significantly.
Here's an example:
#legacySQL
SELECT WEEK(MSEC_TO_TIMESTAMP(1470631859000)) AS sign_up_week;
Output: 33
#standardSQL
SELECT EXTRACT(WEEK FROM TIMESTAMP_MILLIS(1470631859000));
Output: 32
I've viewed the following documentation on the Legacy SQL reference:
WEEK(<timestamp>)
Returns the week of a TIMESTAMP data type as an integer between 1 and 53, inclusively.
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
And from the Standard SQL reference:
WEEK(<WEEKDAY>): Returns the week number of the date in the range [0, 53]. Weeks begin on WEEKDAY. Dates prior to the first WEEKDAY of the year are in week 0. Valid values for WEEKDAY are SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, and SATURDAY.
ISOWEEK: Returns the ISO 8601 week number of the date_expression. ISOWEEKs begin on Monday. Return values are in the range [1, 53]. The first ISOWEEK of each ISO year begins on the Monday before the first Thursday of the Gregorian calendar year.
How can I get my Standard SQL query to output the same week number as my Legacy SQL query? If not, which week number is correct? It does not appear I can get them to dovetail natively.
sql google-bigquery unix-timestamp standard-sql
I am converting an old query from Legacy SQL to Standard SQL and noticed my report was off. I've traced it back to Legacy SQL and Standard SQL returning different weeks based off of a UNIX millisecond timestamp.
I was under the impression the Legacy SQL query was correct, but however, I'm curious to know the difference. It's not across all weeks, but enough to throw my report off significantly.
Here's an example:
#legacySQL
SELECT WEEK(MSEC_TO_TIMESTAMP(1470631859000)) AS sign_up_week;
Output: 33
#standardSQL
SELECT EXTRACT(WEEK FROM TIMESTAMP_MILLIS(1470631859000));
Output: 32
I've viewed the following documentation on the Legacy SQL reference:
WEEK(<timestamp>)
Returns the week of a TIMESTAMP data type as an integer between 1 and 53, inclusively.
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
And from the Standard SQL reference:
WEEK(<WEEKDAY>): Returns the week number of the date in the range [0, 53]. Weeks begin on WEEKDAY. Dates prior to the first WEEKDAY of the year are in week 0. Valid values for WEEKDAY are SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, and SATURDAY.
ISOWEEK: Returns the ISO 8601 week number of the date_expression. ISOWEEKs begin on Monday. Return values are in the range [1, 53]. The first ISOWEEK of each ISO year begins on the Monday before the first Thursday of the Gregorian calendar year.
How can I get my Standard SQL query to output the same week number as my Legacy SQL query? If not, which week number is correct? It does not appear I can get them to dovetail natively.
sql google-bigquery unix-timestamp standard-sql
sql google-bigquery unix-timestamp standard-sql
edited Nov 10 at 15:31
asked Nov 10 at 15:18
Sillson
1119
1119
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
This is a bit subtle, but legacy and standard SQL handle weeks differently. In Legacy SQL:
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
In Standard SQL:
- WEEK: Returns the week number of the date in the range [0, 53]. Weeks begin with Sunday, and dates prior to the first Sunday of the year are in week 0.
So, in Legacy SQL the first Sunday is week 2. In Standard SQL, the first Sunday is week 1.
Although this may be a stupid question, is there any definition that's more 'correct'? I'm hoping to remove the legacy SQL from the codebase. I believe ISOWEEK would fit my purposes better WEEK 1-53 makes more sense for a cohort report, however I'll need to justify the discrepancy in data.
– Sillson
Nov 10 at 16:09
2
Use ISOWEEK if that meets your needs. At least it is a defined standard and will be consistent over time and across platforms.
– Gordon Linoff
Nov 10 at 16:17
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
This is a bit subtle, but legacy and standard SQL handle weeks differently. In Legacy SQL:
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
In Standard SQL:
- WEEK: Returns the week number of the date in the range [0, 53]. Weeks begin with Sunday, and dates prior to the first Sunday of the year are in week 0.
So, in Legacy SQL the first Sunday is week 2. In Standard SQL, the first Sunday is week 1.
Although this may be a stupid question, is there any definition that's more 'correct'? I'm hoping to remove the legacy SQL from the codebase. I believe ISOWEEK would fit my purposes better WEEK 1-53 makes more sense for a cohort report, however I'll need to justify the discrepancy in data.
– Sillson
Nov 10 at 16:09
2
Use ISOWEEK if that meets your needs. At least it is a defined standard and will be consistent over time and across platforms.
– Gordon Linoff
Nov 10 at 16:17
add a comment |
up vote
2
down vote
This is a bit subtle, but legacy and standard SQL handle weeks differently. In Legacy SQL:
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
In Standard SQL:
- WEEK: Returns the week number of the date in the range [0, 53]. Weeks begin with Sunday, and dates prior to the first Sunday of the year are in week 0.
So, in Legacy SQL the first Sunday is week 2. In Standard SQL, the first Sunday is week 1.
Although this may be a stupid question, is there any definition that's more 'correct'? I'm hoping to remove the legacy SQL from the codebase. I believe ISOWEEK would fit my purposes better WEEK 1-53 makes more sense for a cohort report, however I'll need to justify the discrepancy in data.
– Sillson
Nov 10 at 16:09
2
Use ISOWEEK if that meets your needs. At least it is a defined standard and will be consistent over time and across platforms.
– Gordon Linoff
Nov 10 at 16:17
add a comment |
up vote
2
down vote
up vote
2
down vote
This is a bit subtle, but legacy and standard SQL handle weeks differently. In Legacy SQL:
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
In Standard SQL:
- WEEK: Returns the week number of the date in the range [0, 53]. Weeks begin with Sunday, and dates prior to the first Sunday of the year are in week 0.
So, in Legacy SQL the first Sunday is week 2. In Standard SQL, the first Sunday is week 1.
This is a bit subtle, but legacy and standard SQL handle weeks differently. In Legacy SQL:
Weeks begin on Sunday, so if January 1 is on a day other than Sunday, week 1 has fewer than 7 days and the first Sunday of the year is the first day of week 2.
In Standard SQL:
- WEEK: Returns the week number of the date in the range [0, 53]. Weeks begin with Sunday, and dates prior to the first Sunday of the year are in week 0.
So, in Legacy SQL the first Sunday is week 2. In Standard SQL, the first Sunday is week 1.
answered Nov 10 at 15:36
Gordon Linoff
743k32285390
743k32285390
Although this may be a stupid question, is there any definition that's more 'correct'? I'm hoping to remove the legacy SQL from the codebase. I believe ISOWEEK would fit my purposes better WEEK 1-53 makes more sense for a cohort report, however I'll need to justify the discrepancy in data.
– Sillson
Nov 10 at 16:09
2
Use ISOWEEK if that meets your needs. At least it is a defined standard and will be consistent over time and across platforms.
– Gordon Linoff
Nov 10 at 16:17
add a comment |
Although this may be a stupid question, is there any definition that's more 'correct'? I'm hoping to remove the legacy SQL from the codebase. I believe ISOWEEK would fit my purposes better WEEK 1-53 makes more sense for a cohort report, however I'll need to justify the discrepancy in data.
– Sillson
Nov 10 at 16:09
2
Use ISOWEEK if that meets your needs. At least it is a defined standard and will be consistent over time and across platforms.
– Gordon Linoff
Nov 10 at 16:17
Although this may be a stupid question, is there any definition that's more 'correct'? I'm hoping to remove the legacy SQL from the codebase. I believe ISOWEEK would fit my purposes better WEEK 1-53 makes more sense for a cohort report, however I'll need to justify the discrepancy in data.
– Sillson
Nov 10 at 16:09
Although this may be a stupid question, is there any definition that's more 'correct'? I'm hoping to remove the legacy SQL from the codebase. I believe ISOWEEK would fit my purposes better WEEK 1-53 makes more sense for a cohort report, however I'll need to justify the discrepancy in data.
– Sillson
Nov 10 at 16:09
2
2
Use ISOWEEK if that meets your needs. At least it is a defined standard and will be consistent over time and across platforms.
– Gordon Linoff
Nov 10 at 16:17
Use ISOWEEK if that meets your needs. At least it is a defined standard and will be consistent over time and across platforms.
– Gordon Linoff
Nov 10 at 16:17
add a comment |
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%2f53240342%2fbigquery-standard-sql-returns-different-week-from-timestamp%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