Handle DOS dates in Kotlin/Multiplatform #1438
Conversation
This might be foolish. The total amount of new code is relatively small (45 lines of code), but that code does something we don't otherwise want to be doing in Okio - date math. But this unblocks implementing ZipFileSystem in Kotlin/Native.
|
|
||
| /** | ||
| * Roll our own date math because Kotlin doesn't include a built-in date math API, and the | ||
| * kotlinx.datetime library doesn't offer a stable at this time. |
There was a problem hiding this comment.
| * kotlinx.datetime library doesn't offer a stable at this time. | |
| * kotlinx.datetime library doesn't offer a stable release at this time. |
| * This code is broken for out-of-range values. For example, it doesn't correctly implement leap | ||
| * year offsets when the month is -24 or when the day is -365. | ||
| */ | ||
| internal actual fun datePartsToEpochMillis( |
There was a problem hiding this comment.
Why not use this in common? Do we gain anything from using the Java APIs?
There was a problem hiding this comment.
Quite tragically I haven’t yet done the work to use the ‘local time zone’ on Kotlin/Native. So for everything but UTC the Kotlin/Native DOS dates will be off by the time zone offset.
I’ll spend a small effort attempting to fix this? The “extended timestamps” extension (0x5455) means we’ll probably get the correct answer anyway.
There was a problem hiding this comment.
One other option that might make the code simpler: use Java APIs for the timezone adjustment only. That way I can ship one common implementation that uses timezone information where it’s available.
| @@ -102,3 +102,5 @@ expect fun assertRelativeToFails( | |||
| b: Path, | |||
| sameAsNio: Boolean = true, | |||
| ): IllegalArgumentException | |||
|
|
|||
| expect fun <T> withUtc(block: () -> T): T | |||
There was a problem hiding this comment.
...it would eliminate this otherwise weird function that is only for JVM too.
|
I’m gonna do the timezone fixups in a follow-up! |
This might be foolish. The total amount of new code is
relatively small (45 lines of code), but that code does
something we don't otherwise want to be doing in Okio -
date math.
But this unblocks implementing ZipFileSystem in Kotlin/Native.