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

docs: "portable" values are always in UTC, right? #12

Open
pnkfelix opened this issue Sep 5, 2017 · 1 comment
Open

docs: "portable" values are always in UTC, right? #12

pnkfelix opened this issue Sep 5, 2017 · 1 comment

Comments

@pnkfelix
Copy link

pnkfelix commented Sep 5, 2017

When I was hacking up some code to print the actual date/time for a timestamp reported by this library, I was briefly flummoxed when it didn't match the results I saw from ls.

Then I eventually realized that ls was giving me times in my current locale, while this library always produces times relative to UTC.

This is unsurprising; this crate is after all just a thin veneer over utimes (at least on Unix), so the time zone handling is just going to be inherited from whatever the implementation of utimes does.

But: maybe the docs should explicitly note this, at least for fn seconds_relative_to_1970 and fn from_seconds_since_1970.

Just adding "(UTC)" to the description of the epoch would suffice, probably.

  • Looking at the docs now, it doesn't even say "00:00:00" (aka midnight); it just says January 1, 1970. Heh.
  • So maybe the full string "(more specifically, the Epoch: 1970-01-01 00:00:00 +0000 (UTC))" should be written after the occurrences of "January 1, 1970" in the docs.
@alexcrichton
Copy link
Owner

Makes sense to me!

Although I'm not sure if this is UTC 100% of the time, I'd have to check the documentation of the relevant syscalls here to see what they return...

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

No branches or pull requests

2 participants