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

Support for plain Time fields #28406

Open
1 task done
OmarHawk opened this issue Jan 7, 2025 · 2 comments
Open
1 task done

Support for plain Time fields #28406

OmarHawk opened this issue Jan 7, 2025 · 2 comments

Comments

@OmarHawk
Copy link
Contributor

OmarHawk commented Jan 7, 2025

Overview of the feature request

Hi,

while there is currrently support for something like an Instant (datetime(6)) there is currently no support for a plain Time value without a Date. Do you think it makes sense to introduce a new data type here as part of JHIpster itself? If so, I'd like to contribute to this.

Motivation for or Use Case

We have the use case to define opening hours. With the existing fields you can either have a plain String where the user must enter the correct format with : by himself, or have Datetime like fields, where the user is required to enter a useless Date value.
Of course, we could also try to implement this as a blueprint, but I think, data types are part of the jhipster core, and this seems to be a special data type that is currently not supported....

Related issues or PR

Searching for "Time" finds too much unrelated stuff, so idk.

  • Checking this box is mandatory (this is just to show you read everything)
@mshima
Copy link
Member

mshima commented Jan 9, 2025

I am ok with this, changing a database type of a field is not accepted in no major versions, but an annotation can be used.

@OmarHawk
Copy link
Contributor Author

So you mean, this should be implemented with an annotation?

Please note, that this is not a "changed" data type, but a new one, so there should be no backwards compatibility issues as long as one is not using this new type... For consistency reasons I would really vote for having an actual type like Instant, Long, String.... Time.

An Annotation would be useful here to define maybe the resolution of the time (seconds, milliseconds, ...)

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

No branches or pull requests

2 participants