-
Notifications
You must be signed in to change notification settings - Fork 123
Deprecate TimeZone serialization #577
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
base: master
Are you sure you want to change the base?
Conversation
* Remove the `@kotlinx.serialization.Serializable` annotation from `TimeZone` and `FixedOffsetTimeZone`. * Deprecate `TimeZoneSerializer` and `FixedOffsetTimeZoneSerializer` with a warning. * Introduce and deprecate the `.serializer()` functions in their companion objects with a warning. Previously, this function used to be generated by the `kotlinx.serialization` compiler plugin. Fixes #576
| @@ -1,12 +1,11 @@ | |||
| /* | |||
| * Copyright 2019-2021 JetBrains s.r.o. | |||
| * Copyright 2025 JetBrains s.r.o. | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC, we can leave only the start date, not the end date
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove the copyright notices completely: Kotlin/kotlinx.coroutines#4016
| * JSON example: `"Europe/Berlin"` | ||
| */ | ||
| @Deprecated( | ||
| "Serializing TimeZone is discouraged. Please serialize the id String instead.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
id String sounds weird. Maybe you want id: String? Or since this is more of a text message, string id sounds better IMO
| * @sample kotlinx.datetime.test.samples.TimeZoneSamples.usage | ||
| */ | ||
| @Serializable(with = TimeZoneSerializer::class) | ||
| public expect open class TimeZone { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the moment you remove @Serializable(with=...) annotation from type, it is shown as red with SERIALIZER_NOT_FOUND where it was used in any @Serializable user class. Sadly, we do not have any kind of deprecation migration for that; so I suggest raising all @Deprecated here to ERROR just to speedup this process
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to keep it WARNING for now so that people can work around the SERIALIZER_NOT_FOUND issue by adding their own annotation to the TimeZone field. Then, after a migratory period, when we expect such annotations to be removed as well, the deprecation can be promoted to ERROR.
Does this approach make sense?
| @Deprecated("Use offset.totalSeconds", ReplaceWith("offset.totalSeconds")) | ||
| public val totalSeconds: Int | ||
|
|
||
| /** @suppress */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suppress what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The generation of the KDoc for this object.
@kotlinx.serialization.Serializableannotation fromTimeZoneandFixedOffsetTimeZone.TimeZoneSerializerandFixedOffsetTimeZoneSerializerwith a warning..serializer()functions in their companion objects with a warning. Previously, this function used to be generated by thekotlinx.serializationcompiler plugin.Fixes #576