-
Notifications
You must be signed in to change notification settings - Fork 533
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
Easy way to convert timestamp to UTC object? #88
Comments
@rory Wouldn't |
On 06/08/16 17:27, Kang Seonghoon wrote:
D'oh! It looks like it might. I obviously didn't find that in the docs. |
@rory Great! Please close the issue if it worked :)
Huh, that may be confusing indeed. I'll think more about that. |
This provides examples for most of the constructor-like methods on `TimeZone`, examples on the various `Offset` impls, and links `NaiveDateTime` to `TimeZone` so that it's more obvious how you're supposed to do things. This is related to chronotope#88, which is something that I ran into when I started using rust-chrono.
Cross references in the docs between |
uhm. strike that. can we actually go from Utc:: to a DateTime? |
All the methods on |
Yes, I found it eventually. Thanks! In rust/chrono to convert millis UNIX epoch is:
|
|
This commit adds the new constructor `from_timestamp_opt` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of using the `_opt` suffix for fallible functions. As panicking variants on invalid input are deprecated, no panicking variant is provided. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp_opt` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of using the `_opt` suffix for fallible functions. As panicking variants on invalid input are deprecated, no panicking variant is provided. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp_opt` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of using the `_opt` suffix for fallible functions. As panicking variants on invalid input are deprecated, no panicking variant is provided. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp_opt` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of using the `_opt` suffix for fallible functions. As panicking variants on invalid input are deprecated, no panicking variant is provided. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp_opt` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of using the `_opt` suffix for fallible functions. As panicking variants on invalid input are deprecated, no panicking variant is provided. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp_opt` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of using the `_opt` suffix for fallible functions. As panicking variants on invalid input are deprecated, no panicking variant is provided. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp_opt` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of using the `_opt` suffix for fallible functions. As panicking variants on invalid input are deprecated, no panicking variant is provided. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of preferring fallible functions. It avoids however the `_opt` suffix as there is no panicking variant. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - chronotope#88 - chronotope#200 - chronotope#832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of preferring fallible functions. It avoids however the `_opt` suffix as there is no panicking variant. See [this issue](chronotope#815) for discussion about error handling and panics. Closes chronotope#832
This commit adds the new constructor `from_timestamp` to build a `DateTime<Utc>` from a UNIX timestamp. Figuring out how to convert a timestamp into a `DateTime<Utc>` was a common issue: - #88 - #200 - #832 This commit should make `DateTime<Utc>` creation more discoverable and intuitive. This commit respects the current convention of preferring fallible functions. It avoids however the `_opt` suffix as there is no panicking variant. See [this issue](#815) for discussion about error handling and panics. Closes #832
As near as I can tell, the only way to convert a timestamp (i.e. number of seconds since UNIX epoch¹) is with
NaiveDateTime::from_timestamp()
, however that returns a DateTime without a timezone... but if we know the unix epoch time, then we know exactly what second it is? a timestamp of 60 is 00:01 UTC on 1st Jan 1970, it's not like it can be in a some other timezone.How about some method that'll take a unix epoch and return a DateTime in UTC timezone?
¹ I'm aware of leap seconds
The text was updated successfully, but these errors were encountered: