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

Easy way to convert timestamp to UTC object? #88

Closed
amandasaurus opened this issue Aug 6, 2016 · 8 comments · Fixed by #185
Closed

Easy way to convert timestamp to UTC object? #88

amandasaurus opened this issue Aug 6, 2016 · 8 comments · Fixed by #185

Comments

@amandasaurus
Copy link

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

@lifthrasiir
Copy link
Contributor

@rory Wouldn't UTC.timestamp(secs, nanos) be enough for your use case?

@amandasaurus
Copy link
Author

On 06/08/16 17:27, Kang Seonghoon wrote:

@rory https://github.com/rory Wouldn't |UTC.timestamp(secs, nanos)| be
enough for your use case?

D'oh! It looks like it might. I obviously didn't find that in the docs.
I was looking for from_timestamp, so that didn't come up. I'll try
that out. Thanks! 👍

@lifthrasiir
Copy link
Contributor

@rory Great! Please close the issue if it worked :)

I was looking for from_timestamp, so that didn't come up.

Huh, that may be confusing indeed. I'll think more about that.

quodlibetor pushed a commit to quodlibetor/rust-chrono that referenced this issue Nov 12, 2016
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.
@lolgesten
Copy link

Cross references in the docs between DateTime::timestamp and Utc::timestamp would be gold.

@lolgesten
Copy link

uhm. strike that. can we actually go from Utc:: to a DateTime?

@quodlibetor
Copy link
Contributor

All the methods on TimeZone are implemented on Utc, anything that has a type signature that ends with -> DateTime will convert a Utc to a DateTime. Sometimes you need to go by way of dates. So: Utc.ymd(2018, 1, 2).and_hms(1, 1, 1) will result in a DateTime.

@lolgesten
Copy link

Yes, I found it eventually. Thanks! In rust/chrono to convert millis UNIX epoch is:

    let millis = reader.get_time_stamp();
    let seconds = (millis / 1000) as i64;
    let nanos = ((millis % 1000) * 1_000_000) as u32;
    let time_stamp = DateTime::<Utc>::from_utc(NaiveDateTime::from_timestamp(seconds, nanos), Utc);

@quodlibetor
Copy link
Contributor

TimeZone::timestamp will also work, and be less verbose:

let timestamp = Utc.timestamp(seconds, nanos);

demurgos added a commit to demurgos/chrono that referenced this issue Sep 9, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 9, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 9, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 9, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 9, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 10, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 10, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 10, 2023
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
demurgos added a commit to demurgos/chrono that referenced this issue Sep 10, 2023
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
djc pushed a commit that referenced this issue Sep 11, 2023
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
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 a pull request may close this issue.

4 participants