Mixing
How to set correct MySQL JDBC timezone in Spring Boot configuration
DB:
$ mysql --version
mysql Ver 14.14 Distrib 5.6.27, for osx10.10 (x86_64) using EditLine wrapper
Spring Boot: 2.1.1.RELEASE
The error:
2019-01-01 15:56:25.849 ERROR 39957 --- [ restartedMain] com.zaxxer.hikari.pool.HikariPool : HikariPool-1 - Exception during pool initialization.
> :bootRun
java.sql.SQLException: The server time zone value 'AEDT' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.
Relevant parts of my properties file:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC
spring.datasource.username=#####
spring.datasource.password=########
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
What I find odd about this is that the error indicates that the timezone being used it AEDT, and yet I specified UTC in the spring.datasource.url. Does Hikari read something else when it initializes?
It does look very much like Hikari ignores the server timezone setting in the database url in favour of using my own machine's timezone which happens to be 'AEDT' (Melbourne, Australia) - This is unwanted behaviour. I would like Hikari to ignore my own machine's timezone. Does anyone know how to make it do that?
mysql spring-boot hikaricp
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
add a comment |
DB:
$ mysql --version
mysql Ver 14.14 Distrib 5.6.27, for osx10.10 (x86_64) using EditLine wrapper
Spring Boot: 2.1.1.RELEASE
The error:
2019-01-01 15:56:25.849 ERROR 39957 --- [ restartedMain] com.zaxxer.hikari.pool.HikariPool : HikariPool-1 - Exception during pool initialization.
> :bootRun
java.sql.SQLException: The server time zone value 'AEDT' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.
Relevant parts of my properties file:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC
spring.datasource.username=#####
spring.datasource.password=########
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
What I find odd about this is that the error indicates that the timezone being used it AEDT, and yet I specified UTC in the spring.datasource.url. Does Hikari read something else when it initializes?
It does look very much like Hikari ignores the server timezone setting in the database url in favour of using my own machine's timezone which happens to be 'AEDT' (Melbourne, Australia) - This is unwanted behaviour. I would like Hikari to ignore my own machine's timezone. Does anyone know how to make it do that?
mysql spring-boot hikaricp
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
add a comment |
DB:
$ mysql --version
mysql Ver 14.14 Distrib 5.6.27, for osx10.10 (x86_64) using EditLine wrapper
Spring Boot: 2.1.1.RELEASE
The error:
2019-01-01 15:56:25.849 ERROR 39957 --- [ restartedMain] com.zaxxer.hikari.pool.HikariPool : HikariPool-1 - Exception during pool initialization.
> :bootRun
java.sql.SQLException: The server time zone value 'AEDT' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.
Relevant parts of my properties file:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC
spring.datasource.username=#####
spring.datasource.password=########
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
What I find odd about this is that the error indicates that the timezone being used it AEDT, and yet I specified UTC in the spring.datasource.url. Does Hikari read something else when it initializes?
It does look very much like Hikari ignores the server timezone setting in the database url in favour of using my own machine's timezone which happens to be 'AEDT' (Melbourne, Australia) - This is unwanted behaviour. I would like Hikari to ignore my own machine's timezone. Does anyone know how to make it do that?
mysql spring-boot hikaricp
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
DB:
$ mysql --version
mysql Ver 14.14 Distrib 5.6.27, for osx10.10 (x86_64) using EditLine wrapper
Spring Boot: 2.1.1.RELEASE
The error:
2019-01-01 15:56:25.849 ERROR 39957 --- [ restartedMain] com.zaxxer.hikari.pool.HikariPool : HikariPool-1 - Exception during pool initialization.
> :bootRun
java.sql.SQLException: The server time zone value 'AEDT' is unrecognized or represents more than one time zone. You must configure either the server or JDBC driver (via the serverTimezone configuration property) to use a more specifc time zone value if you want to utilize time zone support.
Relevant parts of my properties file:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC
spring.datasource.username=#####
spring.datasource.password=########
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
What I find odd about this is that the error indicates that the timezone being used it AEDT, and yet I specified UTC in the spring.datasource.url. Does Hikari read something else when it initializes?
It does look very much like Hikari ignores the server timezone setting in the database url in favour of using my own machine's timezone which happens to be 'AEDT' (Melbourne, Australia) - This is unwanted behaviour. I would like Hikari to ignore my own machine's timezone. Does anyone know how to make it do that?
mysql spring-boot hikaricp
mysql spring-boot hikaricp
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
edited Jan 1 at 6:04
Michael Coxon
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
asked Jan 1 at 5:24
Michael CoxonMichael Coxon
50931534
50931534
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Set useLegacyDatetimeCode false.
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC&useLegacyDatetimeCode=false
answered Jan 1 at 6:44
sajibsajib
2,4461417
thanks, but I tried that already - no effect whatsoever. As I mentioned, I don't think Hikari is looking at the connection string for timezone settings. Besides, I think theuseLegacyDatetimeCodeworkaround is mostly for Hibernate (which I'm not using)
– Michael Coxon
Jan 1 at 6:58
add a comment |
Add useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false to your connection string:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
add a comment |
Thanks for your answers, but I have found the solution.
As I suspected, Hikari ignores whatever you put in the datasource url (so sorry guys, it doesn't matter what you chuck in there), essentially, it reads the timezone setting from MySQL itself, i.e., whatever the result you see when issuing the command
SELECT @@GLOBAL.time_zone;
in MySQL. In my case, the result was "SYSTEM", which is whatever my local machine it set at. This was AEDT, which is not supported by the MySQL driver and hence my exception.
Running this same query in AWS yielded the value "UTC", which is supported (and, actually what I wanted).
Therefore, I had to set the timezone in my local MySQL server.
Firstly, I had to load the available timezones from my host (Mac OS X) into MySQL. I had to find out where the zoneinfo file was (/usr/share/zoneinfo in my case) then find out out where the `mysql_tzinfo_to_sql' utility was (bin directory of the MySQL installation) and use it to load my local machine's supported timezones. In Mac OS X, I ended up running the command:
/usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Then in MySQL I could run the command
SET GLOBAL time_zone = UTC;
this is a valid timezone, and is synchronized with the cloud based instances.
I think this is a real trap for a lot of people using MySQL with Spring Boot. It will work while people are in supported timezones, but if your development machine should switch to an unsupported timezone, it will quite mysteriously break, I'm surprised that it isn't documented anywhere. The source code of the MySQL Connector/J makes it obvious, but you wouldn't know it otherwise.
Maybe its because MySQL is just so 5 years ago, and I'm an old fossil and, and, well, just get off my lawn!
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
add a comment |
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
});
}
});
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%2f53993181%2fhow-to-set-correct-mysql-jdbc-timezone-in-spring-boot-configuration%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Set useLegacyDatetimeCode false.
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC&useLegacyDatetimeCode=false
answered Jan 1 at 6:44
sajibsajib
2,4461417
thanks, but I tried that already - no effect whatsoever. As I mentioned, I don't think Hikari is looking at the connection string for timezone settings. Besides, I think theuseLegacyDatetimeCodeworkaround is mostly for Hibernate (which I'm not using)
– Michael Coxon
Jan 1 at 6:58
add a comment |
Set useLegacyDatetimeCode false.
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC&useLegacyDatetimeCode=false
answered Jan 1 at 6:44
sajibsajib
2,4461417
thanks, but I tried that already - no effect whatsoever. As I mentioned, I don't think Hikari is looking at the connection string for timezone settings. Besides, I think theuseLegacyDatetimeCodeworkaround is mostly for Hibernate (which I'm not using)
– Michael Coxon
Jan 1 at 6:58
add a comment |
Set useLegacyDatetimeCode false.
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC&useLegacyDatetimeCode=false
answered Jan 1 at 6:44
sajibsajib
2,4461417
Set useLegacyDatetimeCode false.
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&serverTimezone=UTC&useLegacyDatetimeCode=false
answered Jan 1 at 6:44
sajibsajib
2,4461417
answered Jan 1 at 6:44
sajibsajib
2,4461417
answered Jan 1 at 6:44
sajibsajib
2,4461417
answered Jan 1 at 6:44
sajibsajib
2,4461417
2,4461417
thanks, but I tried that already - no effect whatsoever. As I mentioned, I don't think Hikari is looking at the connection string for timezone settings. Besides, I think theuseLegacyDatetimeCodeworkaround is mostly for Hibernate (which I'm not using)
– Michael Coxon
Jan 1 at 6:58
add a comment |
thanks, but I tried that already - no effect whatsoever. As I mentioned, I don't think Hikari is looking at the connection string for timezone settings. Besides, I think theuseLegacyDatetimeCodeworkaround is mostly for Hibernate (which I'm not using)
– Michael Coxon
Jan 1 at 6:58
thanks, but I tried that already - no effect whatsoever. As I mentioned, I don't think Hikari is looking at the connection string for timezone settings. Besides, I think the
useLegacyDatetimeCode workaround is mostly for Hibernate (which I'm not using)– Michael Coxon
Jan 1 at 6:58
thanks, but I tried that already - no effect whatsoever. As I mentioned, I don't think Hikari is looking at the connection string for timezone settings. Besides, I think the
useLegacyDatetimeCode workaround is mostly for Hibernate (which I'm not using)– Michael Coxon
Jan 1 at 6:58
add a comment |
Add useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false to your connection string:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
add a comment |
Add useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false to your connection string:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
add a comment |
Add useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false to your connection string:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
Add useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false to your connection string:
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/avmaint-local?useSSL=false&useUnicode=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=UTC
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
answered Jan 1 at 9:23
user7294900user7294900
22.9k113362
22.9k113362
add a comment |
add a comment |
Thanks for your answers, but I have found the solution.
As I suspected, Hikari ignores whatever you put in the datasource url (so sorry guys, it doesn't matter what you chuck in there), essentially, it reads the timezone setting from MySQL itself, i.e., whatever the result you see when issuing the command
SELECT @@GLOBAL.time_zone;
in MySQL. In my case, the result was "SYSTEM", which is whatever my local machine it set at. This was AEDT, which is not supported by the MySQL driver and hence my exception.
Running this same query in AWS yielded the value "UTC", which is supported (and, actually what I wanted).
Therefore, I had to set the timezone in my local MySQL server.
Firstly, I had to load the available timezones from my host (Mac OS X) into MySQL. I had to find out where the zoneinfo file was (/usr/share/zoneinfo in my case) then find out out where the `mysql_tzinfo_to_sql' utility was (bin directory of the MySQL installation) and use it to load my local machine's supported timezones. In Mac OS X, I ended up running the command:
/usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Then in MySQL I could run the command
SET GLOBAL time_zone = UTC;
this is a valid timezone, and is synchronized with the cloud based instances.
I think this is a real trap for a lot of people using MySQL with Spring Boot. It will work while people are in supported timezones, but if your development machine should switch to an unsupported timezone, it will quite mysteriously break, I'm surprised that it isn't documented anywhere. The source code of the MySQL Connector/J makes it obvious, but you wouldn't know it otherwise.
Maybe its because MySQL is just so 5 years ago, and I'm an old fossil and, and, well, just get off my lawn!
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
add a comment |
Thanks for your answers, but I have found the solution.
As I suspected, Hikari ignores whatever you put in the datasource url (so sorry guys, it doesn't matter what you chuck in there), essentially, it reads the timezone setting from MySQL itself, i.e., whatever the result you see when issuing the command
SELECT @@GLOBAL.time_zone;
in MySQL. In my case, the result was "SYSTEM", which is whatever my local machine it set at. This was AEDT, which is not supported by the MySQL driver and hence my exception.
Running this same query in AWS yielded the value "UTC", which is supported (and, actually what I wanted).
Therefore, I had to set the timezone in my local MySQL server.
Firstly, I had to load the available timezones from my host (Mac OS X) into MySQL. I had to find out where the zoneinfo file was (/usr/share/zoneinfo in my case) then find out out where the `mysql_tzinfo_to_sql' utility was (bin directory of the MySQL installation) and use it to load my local machine's supported timezones. In Mac OS X, I ended up running the command:
/usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Then in MySQL I could run the command
SET GLOBAL time_zone = UTC;
this is a valid timezone, and is synchronized with the cloud based instances.
I think this is a real trap for a lot of people using MySQL with Spring Boot. It will work while people are in supported timezones, but if your development machine should switch to an unsupported timezone, it will quite mysteriously break, I'm surprised that it isn't documented anywhere. The source code of the MySQL Connector/J makes it obvious, but you wouldn't know it otherwise.
Maybe its because MySQL is just so 5 years ago, and I'm an old fossil and, and, well, just get off my lawn!
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
add a comment |
Thanks for your answers, but I have found the solution.
As I suspected, Hikari ignores whatever you put in the datasource url (so sorry guys, it doesn't matter what you chuck in there), essentially, it reads the timezone setting from MySQL itself, i.e., whatever the result you see when issuing the command
SELECT @@GLOBAL.time_zone;
in MySQL. In my case, the result was "SYSTEM", which is whatever my local machine it set at. This was AEDT, which is not supported by the MySQL driver and hence my exception.
Running this same query in AWS yielded the value "UTC", which is supported (and, actually what I wanted).
Therefore, I had to set the timezone in my local MySQL server.
Firstly, I had to load the available timezones from my host (Mac OS X) into MySQL. I had to find out where the zoneinfo file was (/usr/share/zoneinfo in my case) then find out out where the `mysql_tzinfo_to_sql' utility was (bin directory of the MySQL installation) and use it to load my local machine's supported timezones. In Mac OS X, I ended up running the command:
/usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Then in MySQL I could run the command
SET GLOBAL time_zone = UTC;
this is a valid timezone, and is synchronized with the cloud based instances.
I think this is a real trap for a lot of people using MySQL with Spring Boot. It will work while people are in supported timezones, but if your development machine should switch to an unsupported timezone, it will quite mysteriously break, I'm surprised that it isn't documented anywhere. The source code of the MySQL Connector/J makes it obvious, but you wouldn't know it otherwise.
Maybe its because MySQL is just so 5 years ago, and I'm an old fossil and, and, well, just get off my lawn!
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
Thanks for your answers, but I have found the solution.
As I suspected, Hikari ignores whatever you put in the datasource url (so sorry guys, it doesn't matter what you chuck in there), essentially, it reads the timezone setting from MySQL itself, i.e., whatever the result you see when issuing the command
SELECT @@GLOBAL.time_zone;
in MySQL. In my case, the result was "SYSTEM", which is whatever my local machine it set at. This was AEDT, which is not supported by the MySQL driver and hence my exception.
Running this same query in AWS yielded the value "UTC", which is supported (and, actually what I wanted).
Therefore, I had to set the timezone in my local MySQL server.
Firstly, I had to load the available timezones from my host (Mac OS X) into MySQL. I had to find out where the zoneinfo file was (/usr/share/zoneinfo in my case) then find out out where the `mysql_tzinfo_to_sql' utility was (bin directory of the MySQL installation) and use it to load my local machine's supported timezones. In Mac OS X, I ended up running the command:
/usr/local/mysql/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
Then in MySQL I could run the command
SET GLOBAL time_zone = UTC;
this is a valid timezone, and is synchronized with the cloud based instances.
I think this is a real trap for a lot of people using MySQL with Spring Boot. It will work while people are in supported timezones, but if your development machine should switch to an unsupported timezone, it will quite mysteriously break, I'm surprised that it isn't documented anywhere. The source code of the MySQL Connector/J makes it obvious, but you wouldn't know it otherwise.
Maybe its because MySQL is just so 5 years ago, and I'm an old fossil and, and, well, just get off my lawn!
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
answered Jan 1 at 10:19
Michael CoxonMichael Coxon
50931534
50931534
add a comment |
add a comment |
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.
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%2f53993181%2fhow-to-set-correct-mysql-jdbc-timezone-in-spring-boot-configuration%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
