abseil
Repos
4

Events

Created at 1 hour ago
Created at 2 hours ago

Split configuration related to cycle clock into separate headers

PiperOrigin-RevId: 477043101 Change-Id: I009ea39ad61e7e78cdac51afc57a8ad5b4d8aa2d

Created at 3 hours ago
Created at 6 hours ago
Created at 6 hours ago
Created at 7 hours ago
Created at 7 hours ago
Created at 7 hours ago
issue comment
cctz::detail::parse ignore zone validation

You are saying we should not rely on absl::ParseTime to parse time zone?

Yes, in a nutshell.

%Z would not parse a "timezone", but presumably rather a "timezone name or abbreviation", which is ill-defined and/or ambiguous enough to be useless.

I would instead recommend either:

  1. your input strings include a UTC offset, matched by %z, %Ez, or %E*z, and you call absl::ParseTime(format, input, &t, &err), or
  2. your input strings do not contain a UTC offset, and you call absl::ParseTime(format, input, tz, &t, &err), where the input is interpreted within tz.

In the case you cited, option 1 is sufficient and preferred.

Created at 7 hours ago
issue comment
cctz::detail::parse ignore zone validation

oops yes I copied the wrong time format. I meant CAPITAL Z above.

You are saying we should not rely on absl::ParseTime to parse time zone?

Created at 9 hours ago
issue comment
cctz::detail::parse ignore zone validation

example below parse returns true

It looks like it returns false to me.

The code snippet you linked to concerns the %Z (upper-case) specifier instead, which, as mentioned here, shouldn't be used for absl::ParseTime().

Created at 12 hours ago
Created at 12 hours ago

Fix -Wimplicit-int-conversion and -Wsign-conversion warnings in btree.

Certain core libraries in Chrome build with these warnings [1]; btree_map and btree_set cannot be used in those libraries until these warnings are fixed.

[1] https://crbug.com/1292951

PiperOrigin-RevId: 476908396 Change-Id: I32e9ea1eec911e329d6ff00f04fa2e9cfde8660a

Created at 13 hours ago
Created at 14 hours ago
Created at 14 hours ago

Implement Eisel-Lemire for from_chars

This does for float what a recent commit did for double.

Median of 5 runs of "time atod_manual_test pnftd/data/*.txt" user 0m0.730s # Before user 0m0.701s # After (a speed-up of 1.04x) where pnftd is https://github.com/nigeltao/parse-number-fxx-test-data

Part of the reason why this speed-up of 1.04x isn't as dramatic as for the from_chars change is that, out of the 5299993 pnftd test cases, 76.42% produce result_out_of_range for single precision (compared to 1.03% for double precision).

"benchy --reference=srcfs --benchmark_filter='SimpleAtof' :numbers_benchmark" output (which uses deterministic but randomly generated input strings): name old cpu/op new cpu/op delta BM_SimpleAtofabsl::string_view/10/1 392ns ± 2% 323ns ± 3% -17.60% (p=0.000 n=48+48) BM_SimpleAtofabsl::string_view/10/2 426ns ± 3% 311ns ± 4% -26.89% (p=0.000 n=59+49) BM_SimpleAtofabsl::string_view/10/4 435ns ± 3% 341ns ± 3% -21.68% (p=0.000 n=58+48) BM_SimpleAtofabsl::string_view/10/8 501ns ± 3% 393ns ± 3% -21.55% (p=0.000 n=60+50) BM_SimpleAtof<const char*>/10/1 409ns ± 6% 339ns ± 3% -17.06% (p=0.000 n=48+49) BM_SimpleAtof<const char*>/10/2 412ns ± 4% 347ns ± 3% -15.82% (p=0.000 n=47+49) BM_SimpleAtof<const char*>/10/4 463ns ± 6% 369ns ± 6% -20.37% (p=0.000 n=60+50) BM_SimpleAtof<const char*>/10/8 548ns ± 3% 450ns ± 4% -17.91% (p=0.000 n=57+59) BM_SimpleAtofstd::string/10/1 386ns ± 2% 325ns ± 3% -15.74% (p=0.000 n=48+50) BM_SimpleAtofstd::string/10/2 425ns ± 3% 311ns ± 4% -26.79% (p=0.000 n=60+50) BM_SimpleAtofstd::string/10/4 435ns ± 4% 340ns ± 3% -21.94% (p=0.000 n=59+49) BM_SimpleAtofstd::string/10/8 503ns ± 4% 398ns ± 2% -20.89% (p=0.000 n=59+48)

PiperOrigin-RevId: 476880111 Change-Id: Ibc5583677ac2ed338d09d8db960ae8a513eb2ccb

Created at 16 hours ago
Created at 16 hours ago
Created at 16 hours ago
issue comment
cctz::detail::parse ignore zone validation

@devbww

Created at 16 hours ago
Created at 17 hours ago
Created at 20 hours ago
Created at 1 day ago
Created at 1 day ago

Import of CCTZ from GitHub.

PiperOrigin-RevId: 476742468 Change-Id: I99267ad1194b119b59f341ef5044c8836de5bf0e

Created at 1 day ago
Created at 1 day ago
Created at 1 day ago
Created at 1 day ago
Created at 1 day ago
Created at 2 days ago