Closed andoriyu closed 2 years ago
SystemTime
is available on every platform you can write a HTTP server or client I believe. I'm not familiar with rust-embed, do you want to generate the timestamp during compile-time? Converting dates to the HTTP format should have an insignificant impact on performance (but measure it if you want to be certain).
Well, i just have timestamps as u64 because rust-embed only exposes it as u64 because. I think it's due to an option to set it at the compile time.
You know... I didn't realize that i can get SystemTime by adding timestamp
to UNIX_EPOCH
. Even after looking at the tests. I think it's still nice
to have to have an option to use timestamp directly.
On Wed, Oct 19, 2022, 11:25 PM pyfisch @.***> wrote:
SystemTime is available on every platform you can write a HTTP server or client I believe. I'm not familiar with rust-embed, do you want to generate the timestamp during compile-time? Converting dates to the HTTP format should have an insignificant impact on performance (but measure it if you want to be certain).
— Reply to this email directly, view it on GitHub https://github.com/pyfisch/httpdate/pull/10#issuecomment-1285005337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABEFG27IJW3MX25JWCNSRTWEDQWFANCNFSM6AAAAAARJNWB64 . You are receiving this because you authored the thread.Message ID: @.***>
You know... I didn't realize that i can get SystemTime by adding timestamp to
UNIX_EPOCH
.
This would be a good thing to document.
Since the common case is to format the current time (which is already a SystemTime
) and I want to keep the API minimal I prefer not to add an option to use u64
directly.
Sometimes
SystemTime
cannot be obtained, and instead just plain timestamp is the only thing available. For example, using this withrust-embed
is one of those cases.This change:
from_secs_since_epoch
that allows conversion fromu64
toHttpDate
, didn't useFrom<u64>
trait, so it's clear what unit is expected there.From<SystemTime>
to use that new method underneath.