Skip to content

Handle DOS dates in Kotlin/Multiplatform#1438

Merged
swankjesse merged 2 commits intomasterfrom
jwilson.0221.dos_dates
Feb 21, 2024
Merged

Handle DOS dates in Kotlin/Multiplatform#1438
swankjesse merged 2 commits intomasterfrom
jwilson.0221.dos_dates

Conversation

@swankjesse
Copy link
Copy Markdown
Collaborator

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.

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.
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use this in common? Do we gain anything from using the Java APIs?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

sameAsNio: Boolean = true,
): IllegalArgumentException

expect fun <T> withUtc(block: () -> T): T
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...it would eliminate this otherwise weird function that is only for JVM too.

@swankjesse
Copy link
Copy Markdown
Collaborator Author

I’m gonna do the timezone fixups in a follow-up!

@swankjesse swankjesse merged commit 3bcb813 into master Feb 21, 2024
@swankjesse swankjesse deleted the jwilson.0221.dos_dates branch February 21, 2024 14:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants