Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 23 21:04
    quodlibetor commented #331
  • Aug 23 20:54
    evq commented #331
  • Aug 23 20:51
    evq commented #331
  • Aug 23 19:55
    quodlibetor commented #331
  • Aug 23 19:54

    quodlibetor on master

    Add {Utc,Local}::now() construc… fix local timezone, add tests add conditionals so wasm tests … and 9 more (compare)

  • Aug 23 19:54
    quodlibetor closed #331
  • Aug 22 09:14
    evq synchronize #331
  • Aug 21 17:00
    quodlibetor milestoned #332
  • Aug 21 17:00
    quodlibetor labeled #332
  • Aug 21 17:00
    quodlibetor labeled #332
  • Aug 21 16:59
    quodlibetor commented #332
  • Aug 21 07:35
    matiu2 edited #332
  • Aug 21 07:35
    matiu2 opened #332
  • Aug 20 18:53
    ctaggart commented #284
  • Aug 20 18:53
    ctaggart commented #284
  • Aug 20 15:28
    quodlibetor commented #331
  • Aug 20 04:29
    evq commented #331
  • Aug 16 23:19
    evq commented #331
  • Aug 16 22:57
    evq commented #331
  • Aug 16 22:46
    evq commented #331
Norberto Lopes
@nlopes
That basically gives me a Err(ParseError(BadFormat))
Norberto Lopes
@nlopes
Ha, I think I missed this bit in the docs: "%Z ACST Formatting only: Local time zone name." (the Formatting only is important)
Is there another elegant way to parse that string?
Casey Marshall
@cmars
hi, can i get a review of chronotope/chrono#292 ?
Brandon W Maister
@quodlibetor
hi!
yes
Casey Marshall
@cmars
awesome, ty
Frank Prößdorf
@endor
I'm looking for an efficient way to calculate the difference in milliseconds between two dates I have as strings. Currently I'm using chrono and doing something like this: https://gist.github.com/endor/09339daf97ea33418ab69492d8f2cb75. Is there a more efficient way?
Brandon W Maister
@quodlibetor
based on the complexity of that I assume you already tried chrono's format parsing functions? I wouldn't expect them to be faster than your code but I am curious what the performance difference is
Frank Prößdorf
@endor
I tried them yes. With just some basic Instant::now,elapsed()/println! I think the difference was ~1000ns or so, if I remember correctly. I think there would be some performance improvement if I could instantiate a DateTime without all the checks. Not sure how to do that and if that would actually save a lot of time.
John
@onFireForGod_gitlab
I have a pacific standard time that I will be receiving, and I will need to store it in UTC, how should I convert?
Basically the cleint will have the timezones in their requests and I will convert them using the timezone they provided, is this achievable with the chrono library?
Brandon W Maister
@quodlibetor
it is achievable
John
@onFireForGod_gitlab
What should the appraoch be?
I was thinking using fixed offset
then converting it somehow into UTC but can’t find how
Brandon W Maister
@quodlibetor
if the timezone is coming in as an offset (not a name) then yes fixedoffset is the way to go
looking for the docs
if you parse it into a datetime mydt you should be able to do mydt.with_timezone(Utc) https://docs.rs/chrono/0.4.6/chrono/struct.DateTime.html#method.with_timezone
John
@onFireForGod_gitlab
awesome!
thanks
Brandon W Maister
@quodlibetor
np
John
@onFireForGod_gitlab
If no offset is given and just for example 'America/Los_Angeles’ and the time is given, does chrono provide functionality to convert to UTC?
Brandon W Maister
@quodlibetor
The right way to do that is to use chrono-tz: https://github.com/chronotope/chrono-tz
John
@onFireForGod_gitlab
k thanks
John
@onFireForGod_gitlab
I get a panic,
[src/bin/seed/csv_parse.rs:35] date.and_hms(dbg!(hour), 0, 0) = 1993-04-04T02:00:00
thread 'main' panicked at 'No such local time',
let pacific_time = Pacific.from_local_datetime(&dbg!(date.and_hms(dbg!(hour), 0, 0))).unwrap();
oh, daylight saving
I thought it starts second week of march?
Okay I see that rule only applies after 2005
Brandon W Maister
@quodlibetor
time doesn't exist
specifically that time
I'm glad it works for you!
John
@onFireForGod_gitlab
why are their ambigous results on conversion?
nevermind
is there only one ambigous result for the whole year?
because when transitioning to daylight it just skips an hour
while transitioning back to standard will yeild two hours which is where ambiguity comes in
Brandon W Maister
@quodlibetor
other than leap seconds I believe that that is correct
actually, sometimes governments decide to just change the time, which would also cause that. It doesn't happen much, though
John
@onFireForGod_gitlab
Think I found a bug
let tz: Tz = dbg!(timezone.parse().map_err(|e| format!("{}", e)))?; 
let local = match dbg!(tz.from_local_datetime(dbg!(date))) {
[src/actors/date_converter.rs:16] timezone.parse().map_err(|e| format!("{}" , e)) = Ok(
    America/Los_Angeles
)
[src/actors/date_converter.rs:17] date = 2019-04-10T02:59:00
[src/actors/date_converter.rs:17] tz.from_local_datetime(dbg!(date)) = Single(
    2019-04-10T02:59:00PDT
)
the time 2019-04-10T02:59:00 does not exist in PDT, however it is returning a result
if I provide 2019-04-10Y02:01:00 instead, it does the correct thing and return none:
[src/actors/date_converter.rs:16] timezone.parse().map_err(|e| format!("{}" , e)) = Ok(
    America/Los_Angeles
)
[src/actors/date_converter.rs:17] date = 2019-03-10T02:01:00
[src/actors/date_converter.rs:17] tz.from_local_datetime(dbg!(date)) = None
here are two side by side, with one of them a minute before the other
[src/actors/date_converter.rs:16] timezone.parse().map_err(|e| format!("{}" , e)) = Ok(
    America/Los_Angeles
)
[src/actors/date_converter.rs:17] date = 2019-03-10T02:58:00
[src/actors/date_converter.rs:17] tz.from_local_datetime(dbg!(date)) = None
[src/actors/date_converter.rs:16] timezone.parse().map_err(|e| format!("{}" , e)) = Ok(
    America/Los_Angeles
)
[src/actors/date_converter.rs:17] date = 2019-04-10T02:59:00
[src/actors/date_converter.rs:17] tz.from_local_datetime(dbg!(date)) = Single(
    2019-04-10T02:59:00PDT
)
John
@onFireForGod_gitlab
2019-04-10T03:00:00PDTshould exists. However 2019-04-10T02:59:00PDTshould return none right?
Brandon W Maister
@quodlibetor
that... does seem right
or, wrong
zerocity
@zerocity

Hi,

i get quite frustrated to parse timestamps, could some one help me ?
{
...

#[serde(with = "ts_nanoseconds")]
pub time_usec: NaiveDateTime

...
}
time_usec: 1_554_806_625_883_298
but i get a complete strange date like 1970 ....
I think i am complete on the wrong way :)

Brandon W Maister
@quodlibetor
that variable looks like you're expecting microseconds, but you're using a nanosecond parser, which will be 1,000 times less distant into the future
try ts_microseconds