Hi!

I would like to know how the proposal handles zonefile updates, assume that
my program start and then a while later there is a new zonefile, how do I
tell the library that it need to rereaad it?

If load_time_zone always rereads the zonefile then I think that should be
spelled out.

/MF

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--94eb2c08192a632576052c223b8e
Content-Type: text/plain; charset=UTF-8

Hi, Magnus.

Our library as described in the paper will cache the loaded time-zone data
when it is first requested, and will return the cached data on all
subsequent calls for the life of the process. To re-read the data you would
need to restart the process.

I'm unable to update the published document (p0216r0), but I did update the
source copy of the paper on GitHub (https://github.com/devjgm/papers).

Greg

On Fri, Feb 19, 2016 at 3:16 AM Magnus Fromreide <magfr@lysator.liu.se>
wrote:

> Hi!
>
> I would like to know how the proposal handles zonefile updates, assume that
> my program start and then a while later there is a new zonefile, how do I
> tell the library that it need to rereaad it?
>
> If load_time_zone always rereads the zonefile then I think that should be
> spelled out.
>
> /MF
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--94eb2c08192a632576052c223b8e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,=C2=A0Magnus.<div><br></div><div>Our library as describ=
ed in the paper will cache the loaded time-zone data when it is first reque=
sted, and will return the cached data on all subsequent calls for the life =
of the process. To re-read the data you would need to restart the process.<=
/div><div><br></div><div>I&#39;m unable to update the published document (p=
0216r0), but I did update the source copy of the paper on GitHub (<a href=
=3D"https://github.com/devjgm/papers" class=3D"cremed">https://github.com/d=
evjgm/papers</a>).</div><div><br></div><div>Greg</div><div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Fri, Feb 19, 2016 at 3:16 AM Magnus Fr=
omreide &lt;<a href=3D"mailto:magfr@lysator.liu.se">magfr@lysator.liu.se</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
I would like to know how the proposal handles zonefile updates, assume that=
<br>
my program start and then a while later there is a new zonefile, how do I<b=
r>
tell the library that it need to rereaad it?<br>
<br>
If load_time_zone always rereads the zonefile then I think that should be<b=
r>
spelled out.<br>
<br>
/MF<br>
</blockquote></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--94eb2c08192a632576052c223b8e--

.

On sexta-feira, 19 de fevereiro de 2016 16:46:49 PST 'Greg Miller' via ISO C++
Standard - Future Proposals wrote:
> Our library as described in the paper will cache the loaded time-zone data
> when it is first requested, and will return the cached data on all
> subsequent calls for the life of the process. To re-read the data you would
> need to restart the process.

Please consider a method to reload the cached data for applications that run
for two or more months before restarting.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 02/19/2016 05:46 PM, 'Greg Miller' via ISO C++ Standard - Future Proposals wrote:
> Hi, Magnus.
>
> Our library as described in the paper will cache the loaded time-zone data when it is first requested, and will return the cached data on all subsequent calls for the life of the process. To re-read the data you would need to restart the process.

This is not a workable design for my problem domain, where
I have long-running server processes (maybe running for months
at a time), but timezone changes (in particular concerning
daylight savings time) come in a lot more often,
and on short notice (e.g. a week or two before becoming
effective).

A timezone library that does not allow for some kind of
explicit re-load is dead-on-arrival for my use case.

> I'm unable to update the published document (p0216r0)

Good, that's as it should be.

> , but I did update the source copy of the paper on GitHub (https://github.com/devjgm/papers).

Are you going to present the paper in Jacksonville?

If so, make sure the updated version is uploaded to the meeting wiki
as D0216R1 (this can be edited throughout the meeting and
should be published post-meeting as P0216P1).

Thanks,
Jens

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-02-19 11:46, 'Greg Miller' wrote:
> Our library as described in the paper will cache the loaded time-zone dat=
a
> when it is first requested, and will return the cached data on all
> subsequent calls for the life of the process. To re-read the data you wou=
ld
> need to restart the process.

Please see / consider Thiago's and Jens' comments. I would feel strongly
about rejecting such a design for the standard library.

A way to reload the data is critically needed. (Ideally it would happen
automatically=C2=B9; if not, a way to force an update is needed.)

(=C2=B9 For example, if the last time the DB was checked is greater than so=
me
threshold -  say, 24 hours - then the DB will be `stat()`d to see if it
needs to be re-read. If not, this resets the timer, naturally. This way
you get reasonable assurance that at least the current time is correct=C2=
=B2,
with very low overhead for subsequent checks; just a stat() every 24
hours, except when the DB changes.)

(=C2=B2 Obviously there's nothing you can do if someone asks about a time
some years in the future, and the TZ rules change between the request
and the time requested. No one expects the library to implement
precognition ;-).)

BTW, this doesn't apply just to server processes. It's common for my
desktop, including DE processes, to be up for months at a time (current
uptime: 86 days). It would be annoying if the clock on my taskbar was
wrong because it used the standard TZ library and was unable as a result
to reflect TZ changes since logging in.

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

On sexta-feira, 19 de fevereiro de 2016 12:18:59 PST Matthew Woehlke wrote:
> (=C2=B9 For example, if the last time the DB was checked is greater than =
some
> threshold -  say, 24 hours - then the DB will be `stat()`d to see if it
> needs to be re-read. If not, this resets the timer, naturally. This way
> you get reasonable assurance that at least the current time is correct=C2=
=B2,
> with very low overhead for subsequent checks; just a stat() every 24
> hours, except when the DB changes.)

That's one stat() every 24 hours but one gettimeofday() call at every use. =
On=20
Linux, that's fast (clock_gettime with CLOCK_REALTIME_COARSE even more so),=
=20
but it doesn't mean it is fast on all systems.

Just mentioning so that this consequence can be factored in the decision-
making of which mode should be the default.

C++ usually opts for "don't pay for what you don't use", which would mean=
=20
don't try to automatically reload; I would opt for the other way, as otherw=
ise=20
people would not realise they need to because people don't test application=
s=20
running for two months. And because you usually only get bug reports about=
=20
daylight savings twice a year.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

On 2016-02-19 12:32, Thiago Macieira wrote:
> On sexta-feira, 19 de fevereiro de 2016 12:18:59 PST Matthew Woehlke wrot=
e:
>> (=C2=B9 For example, if the last time the DB was checked is greater than=
 some
>> threshold -  say, 24 hours - then the DB will be `stat()`d to see if it
>> needs to be re-read. If not, this resets the timer, naturally. This way
>> you get reasonable assurance that at least the current time is correct=
=C2=B2,
>> with very low overhead for subsequent checks; just a stat() every 24
>> hours, except when the DB changes.)
>=20
> That's one stat() every 24 hours but one gettimeofday() call at every use=
.. On=20
> Linux, that's fast (clock_gettime with CLOCK_REALTIME_COARSE even more so=
),=20
> but it doesn't mean it is fast on all systems.

It's probably still faster than reading the entire DB :-). Still, it's a
fair point.

> Just mentioning so that this consequence can be factored in the decision-
> making of which mode should be the default.

On further thought, I would prefer that caching is an implementation
detail, with DB updates being "noticed in a timely fashion" left as a
QoI issue. I say this because it's conceivable that an implementation
might call a kernel function that is known to always have the current
database, and that any caching is a kernel function and not a function
of the C++ library implementation. That said...

> C++ usually opts for "don't pay for what you don't use", which would mean=
=20
> don't try to automatically reload; I would opt for the other way, as othe=
rwise=20
> people would not realise they need to because people don't test applicati=
ons=20
> running for two months. And because you usually only get bug reports abou=
t=20
> daylight savings twice a year.

....that's not to say I don't agree with this, because I do; a "correct"
implementation should 'automagically' notice changes to the DB, at least
within some reasonable latancy (e.g. 24 hours).

--=20
Matthew

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.

On 19 February 2016 at 20:03, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> ...that's not to say I don't agree with this, because I do; a "correct"
> implementation should 'automagically' notice changes to the DB, at least
> within some reasonable latancy (e.g. 24 hours).


What if the DB is updated via a custom mechanism that the library doesn't know
about? In that case, the library can't auto-reload.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-02-19 13:51, Ville Voutilainen wrote:
> On 19 February 2016 at 20:03, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> ...that's not to say I don't agree with this, because I do; a "correct"
>> implementation should 'automagically' notice changes to the DB, at least
>> within some reasonable latancy (e.g. 24 hours).
>
> What if the DB is updated via a custom mechanism that the library doesn't know
> about? In that case, the library can't auto-reload.

Why not? It would have to do an actual, forcible reload periodically,
but it could still do that. (Do any such implementations actually exist?)

This should probably be discussed by folks that are domain experts in TZ
databases. I am not one of those people. I can state - from the
perspective of a user, not an implementer - what features it *must* have
(able to reflect changes to the DB since the process was started), and
what features I would *like* it to have (automagic refresh), but not
what features are actually possible, or what implementation
considerations apply.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 19 February 2016 at 21:18, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> What if the DB is updated via a custom mechanism that the library doesn't know
>> about? In that case, the library can't auto-reload.
>
> Why not? It would have to do an actual, forcible reload periodically,
> but it could still do that. (Do any such implementations actually exist?)

Well, sure, it can accept a hook that it calls periodically. I don't
know whether
such implementations exist, but I wouldn't mind being able to write them.

> This should probably be discussed by folks that are domain experts in TZ
> databases. I am not one of those people. I can state - from the
> perspective of a user, not an implementer - what features it *must* have
> (able to reflect changes to the DB since the process was started), and

Yep. Being able to somehow reflect changes is rather important, because
there are platforms and applications where restarting a process means rebooting
the machine.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Fri, Feb 19, 2016 at 8:53 AM, Thiago Macieira <thiago@macieira.org> wrote:
> On sexta-feira, 19 de fevereiro de 2016 16:46:49 PST 'Greg Miller' via ISO C++
> Standard - Future Proposals wrote:
>> Our library as described in the paper will cache the loaded time-zone data
>> when it is first requested, and will return the cached data on all
>> subsequent calls for the life of the process. To re-read the data you would
>> need to restart the process.
>
> Please consider a method to reload the cached data for applications that run
> for two or more months before restarting.

Greg, is the "load once per process" forced by some part of the
design, or is it just how the existing implementation happens to work,
because of the environment it was developed in? It's probably worth
sketching some options for reloading in the R1 version of the paper,
which, as Jens says, you can upload to the meeting wiki.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-02-19 14:24, Ville Voutilainen wrote:
> On 19 February 2016 at 21:18, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> What if the DB is updated via a custom mechanism that the library doesn't know
>>> about? In that case, the library can't auto-reload.
>>
>> Why not? It would have to do an actual, forcible reload periodically,
>> but it could still do that. (Do any such implementations actually exist?)
>
> Well, sure, it can accept a hook that it calls periodically. I don't
> know whether such implementations exist, but I wouldn't mind being
> able to write them.

Wait... the TZ data ("the DB") is provided by the library, not the user,
no? How this data is obtained would be an implementation detail, would
it not?

I don't see where a "hook" would be applicable. The library
implementation contains the code to access the TZ data; the user has no
control over this (unless the library provides it). If necessary, that
code could contain logic to reload the TZ data (if it's even being
cached at the library level at all) periodically; pessimistically, if
need be. Since this is all implementation details, I don't see where
there is a problem?

There may be an argument here to provide a standard API to change how
often the DB is refreshed (which might be a no-op on some platforms)...

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 19 February 2016 at 21:53, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> Why not? It would have to do an actual, forcible reload periodically,
>>> but it could still do that. (Do any such implementations actually exist?)
>>
>> Well, sure, it can accept a hook that it calls periodically. I don't
>> know whether such implementations exist, but I wouldn't mind being
>> able to write them.
>
> Wait... the TZ data ("the DB") is provided by the library, not the user,
> no? How this data is obtained would be an implementation detail, would
> it not?

There is a difference between the data and the api to access the data.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c1697c037ae2052c24e67f
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 19, 2016 at 2:49 PM Jeffrey Yasskin <jyasskin@google.com> wrote:

> On Fri, Feb 19, 2016 at 8:53 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
> > On sexta-feira, 19 de fevereiro de 2016 16:46:49 PST 'Greg Miller' via
> ISO C++
> > Standard - Future Proposals wrote:
> >> Our library as described in the paper will cache the loaded time-zone
> data
> >> when it is first requested, and will return the cached data on all
> >> subsequent calls for the life of the process. To re-read the data you
> would
> >> need to restart the process.
> >
> > Please consider a method to reload the cached data for applications that
> run
> > for two or more months before restarting.
>
> Greg, is the "load once per process" forced by some part of the
> design, or is it just how the existing implementation happens to work,
> because of the environment it was developed in? It's probably worth
> sketching some options for reloading in the R1 version of the paper,
> which, as Jens says, you can upload to the meeting wiki.
>

The "load once per process" is just an implementation choice. The overall
design is unaffected by this decision. The ability to reload the data is
certainly a possibility.

Note that I didn't see the email suggesting to consider a method to reload
the cached data. Perhaps I'm not on some necessary mailing list. But now
that I see it, I will add more detail and see about uploading some
uploading some updates to the meeting wiki.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c1697c037ae2052c24e67f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri=
, Feb 19, 2016 at 2:49 PM Jeffrey Yasskin &lt;<a href=3D"mailto:jyasskin@go=
ogle.com">jyasskin@google.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">On Fri, Feb 19, 2016 at 8:53 AM, Thiago Macieira &lt;<a href=3D"m=
ailto:thiago@macieira.org" target=3D"_blank" class=3D"cremed">thiago@maciei=
ra.org</a>&gt; wrote:<br>
&gt; On sexta-feira, 19 de fevereiro de 2016 16:46:49 PST &#39;Greg Miller&=
#39; via ISO C++<br>
&gt; Standard - Future Proposals wrote:<br>
&gt;&gt; Our library as described in the paper will cache the loaded time-z=
one data<br>
&gt;&gt; when it is first requested, and will return the cached data on all=
<br>
&gt;&gt; subsequent calls for the life of the process. To re-read the data =
you would<br>
&gt;&gt; need to restart the process.<br>
&gt;<br>
&gt; Please consider a method to reload the cached data for applications th=
at run<br>
&gt; for two or more months before restarting.<br>
<br>
Greg, is the &quot;load once per process&quot; forced by some part of the<b=
r>
design, or is it just how the existing implementation happens to work,<br>
because of the environment it was developed in? It&#39;s probably worth<br>
sketching some options for reloading in the R1 version of the paper,<br>
which, as Jens says, you can upload to the meeting wiki.<br></blockquote><d=
iv><br></div><div>The &quot;load once per process&quot; is just an implemen=
tation choice. The overall design is unaffected by this decision. The abili=
ty to reload the data is certainly a possibility.</div><div><br></div><div>=
Note that I didn&#39;t see the email suggesting to consider a method to rel=
oad the cached data. Perhaps I&#39;m not on some necessary mailing list. Bu=
t now that I see it, I will add more detail and see about uploading some up=
loading some updates to the meeting wiki.=C2=A0</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11c1697c037ae2052c24e67f--

.

On 2016-02-19 14:55, Ville Voutilainen wrote:
> On 19 February 2016 at 21:53, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>>> Why not? It would have to do an actual, forcible reload periodically,
>>>> but it could still do that. (Do any such implementations actually exist?)
>>>
>>> Well, sure, it can accept a hook that it calls periodically. I don't
>>> know whether such implementations exist, but I wouldn't mind being
>>> able to write them.
>>
>> Wait... the TZ data ("the DB") is provided by the library, not the user,
>> no? How this data is obtained would be an implementation detail, would
>> it not?
>
> There is a difference between the data and the api to access the data.

Sorry, I guess I don't understand what problem you're seeing that would
affect the specification of the API.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 19 February 2016 at 22:17, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>>> Wait... the TZ data ("the DB") is provided by the library, not the user,
>>> no? How this data is obtained would be an implementation detail, would
>>> it not?
>>
>> There is a difference between the data and the api to access the data.
>
> Sorry, I guess I don't understand what problem you're seeing that would
> affect the specification of the API.


I'm envisioning uses where the library doesn't know/care where to load the data
from. That is, it could be provided via a custom mechanism, rather
than as an internal
detail of the library. That would of course be problematic since the
format of the
data would need to be specified for such solutions to be portable.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2016-02-19 15:23, Ville Voutilainen wrote:
> On 19 February 2016 at 22:17, Matthew Woehlke wrote:
>>>> Wait... the TZ data ("the DB") is provided by the library, not the user,
>>>> no? How this data is obtained would be an implementation detail, would
>>>> it not?
>>>
>>> There is a difference between the data and the api to access the data.
>>
>> Sorry, I guess I don't understand what problem you're seeing that would
>> affect the specification of the API.
>
> I'm envisioning uses where the library doesn't know/care where to
> load the data from. That is, it could be provided via a custom
> mechanism, rather than as an internal detail of the library. That
> would of course be problematic since the format of the data would
> need to be specified for such solutions to be portable.

Ah... I had a feeling that what you were thinking. I'm envisioning that
the library would not provide such an ability :-).

Probably if it did, it would be by "feeding" it a class with a known
interface that is used to look up the data. Depending on that API, it
may be that the interface itself would be responsible for ensuring the
"freshness" of the data, or the interface might include a method to
check if the data needs to be updated (i.e. your "hook").

I don't have a strong opinion whether there should be a way for the user
(as opposed to the platform) to provide the TZ data, but I don't offhand
feel that it's needed.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a113f943cd04475052c25b7a4
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 19, 2016 at 11:57 AM, Greg Miller <jgm@google.com> wrote:

>
>
> On Fri, Feb 19, 2016 at 2:49 PM Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>
>> On Fri, Feb 19, 2016 at 8:53 AM, Thiago Macieira <thiago@macieira.org>
>> wrote:
>> > On sexta-feira, 19 de fevereiro de 2016 16:46:49 PST 'Greg Miller' via
>> ISO C++
>> > Standard - Future Proposals wrote:
>> >> Our library as described in the paper will cache the loaded time-zone
>> data
>> >> when it is first requested, and will return the cached data on all
>> >> subsequent calls for the life of the process. To re-read the data you
>> would
>> >> need to restart the process.
>> >
>> > Please consider a method to reload the cached data for applications
>> that run
>> > for two or more months before restarting.
>>
>> Greg, is the "load once per process" forced by some part of the
>> design, or is it just how the existing implementation happens to work,
>> because of the environment it was developed in? It's probably worth
>> sketching some options for reloading in the R1 version of the paper,
>> which, as Jens says, you can upload to the meeting wiki.
>>
>
> The "load once per process" is just an implementation choice. The overall
> design is unaffected by this decision. The ability to reload the data is
> certainly a possibility.
>
> Note that I didn't see the email suggesting to consider a method to reload
> the cached data. Perhaps I'm not on some necessary mailing list. But now
> that I see it, I will add more detail and see about uploading some
> uploading some updates to the meeting wiki.
>

Check out
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/qhJk0PX8Y1I/discussion
for the rest of this discussion.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmG0QSajxnRtW8wR2%3DdtNWBuqJP7-bP7x6%2BAFB77nshdg%40mail.gmail.com.

--001a113f943cd04475052c25b7a4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 19, 2016 at 11:57 AM, Greg Miller <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jgm@google.com" target=3D"_blank" class=3D"cremed">jgm@google.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><br><div class=
=3D"gmail_quote"><div><div class=3D"h5"><div dir=3D"ltr">On Fri, Feb 19, 20=
16 at 2:49 PM Jeffrey Yasskin &lt;<a href=3D"mailto:jyasskin@google.com" ta=
rget=3D"_blank" class=3D"cremed">jyasskin@google.com</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">On Fri, Feb 19, 2016 at 8:53 AM, Thiago Macieira &lt;<a =
href=3D"mailto:thiago@macieira.org" target=3D"_blank" class=3D"cremed">thia=
go@macieira.org</a>&gt; wrote:<br>
&gt; On sexta-feira, 19 de fevereiro de 2016 16:46:49 PST &#39;Greg Miller&=
#39; via ISO C++<br>
&gt; Standard - Future Proposals wrote:<br>
&gt;&gt; Our library as described in the paper will cache the loaded time-z=
one data<br>
&gt;&gt; when it is first requested, and will return the cached data on all=
<br>
&gt;&gt; subsequent calls for the life of the process. To re-read the data =
you would<br>
&gt;&gt; need to restart the process.<br>
&gt;<br>
&gt; Please consider a method to reload the cached data for applications th=
at run<br>
&gt; for two or more months before restarting.<br>
<br>
Greg, is the &quot;load once per process&quot; forced by some part of the<b=
r>
design, or is it just how the existing implementation happens to work,<br>
because of the environment it was developed in? It&#39;s probably worth<br>
sketching some options for reloading in the R1 version of the paper,<br>
which, as Jens says, you can upload to the meeting wiki.<br></blockquote><d=
iv><br></div></div></div><div>The &quot;load once per process&quot; is just=
 an implementation choice. The overall design is unaffected by this decisio=
n. The ability to reload the data is certainly a possibility.</div><div><br=
></div><div>Note that I didn&#39;t see the email suggesting to consider a m=
ethod to reload the cached data. Perhaps I&#39;m not on some necessary mail=
ing list. But now that I see it, I will add more detail and see about uploa=
ding some uploading some updates to the meeting wiki.=C2=A0</div></div></di=
v>
</blockquote></div><br></div><div class=3D"gmail_extra">Check out=C2=A0<a h=
ref=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposals/qhJk0PX=
8Y1I/discussion">https://groups.google.com/a/isocpp.org/d/topic/std-proposa=
ls/qhJk0PX8Y1I/discussion</a> for the rest of this discussion.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXmG0QSajxnRtW8wR2%3DdtNWBuqJP7-=
bP7x6%2BAFB77nshdg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmG0QSa=
jxnRtW8wR2%3DdtNWBuqJP7-bP7x6%2BAFB77nshdg%40mail.gmail.com</a>.<br />

--001a113f943cd04475052c25b7a4--

.

On Fri, Feb 19, 2016 at 03:50:45PM -0500, Matthew Woehlke wrote:
> On 2016-02-19 15:23, Ville Voutilainen wrote:
> > On 19 February 2016 at 22:17, Matthew Woehlke wrote:
> >>>> Wait... the TZ data ("the DB") is provided by the library, not the user,
> >>>> no? How this data is obtained would be an implementation detail, would
> >>>> it not?
> >>>
> >>> There is a difference between the data and the api to access the data.
> >>
> >> Sorry, I guess I don't understand what problem you're seeing that would
> >> affect the specification of the API.
> >
> > I'm envisioning uses where the library doesn't know/care where to
> > load the data from. That is, it could be provided via a custom
> > mechanism, rather than as an internal detail of the library. That
> > would of course be problematic since the format of the data would
> > need to be specified for such solutions to be portable.
>
> Ah... I had a feeling that what you were thinking. I'm envisioning that
> the library would not provide such an ability :-).
>
> Probably if it did, it would be by "feeding" it a class with a known
> interface that is used to look up the data. Depending on that API, it
> may be that the interface itself would be responsible for ensuring the
> "freshness" of the data, or the interface might include a method to
> check if the data needs to be updated (i.e. your "hook").
>
> I don't have a strong opinion whether there should be a way for the user
> (as opposed to the platform) to provide the TZ data, but I don't offhand
> feel that it's needed.

From your discussion I do get the feeling that you are all assuming that once
the library reloads the database all existing time_zone objects are
automatically updated, otherwise, how will the automatic updating tell the
application that it have to fetch new time_zone instances? If that is the
case then how does that interact with multithreading?

Could one not imagine a method on the library

bool bikeshed(); // ok, maybe "reload_time_zone" is a better name

which the user could call periodically if they are interested in getting
updates and which returns true if the database is updated and false otherwise.

This also have the advantage that the user code gets told that the database
is changed so that it knows all it's time_zone objects are potentially stale
and can refetch them.

/MF

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20160219214839.GA5444%40noemi.

.

------=_Part_1803_879234366.1455919466632
Content-Type: multipart/alternative;
 boundary="----=_Part_1804_1375990975.1455919466632"

------=_Part_1804_1375990975.1455919466632
Content-Type: text/plain; charset=UTF-8

Thanks for all the discussion here, folks. Now that I've read this thread,
I'd like to quickly reiterate that whether or not and how the data is
reloaded is not a critical part of the API. The fundamental conceptual
model about how users should think about time zones should not be affected
by this decision. However, you've all raised good points that should be
discussed, so I will flesh out a new section in my doc listing various
options, and I'll upload that draft to the wiki.

I will also be at the Jacksonville meeting in person and I look forward to
discussing this further.

Thank you.
Greg

On Friday, February 19, 2016 at 3:16:58 AM UTC-5, Magnus Fromreide wrote:
>
> Hi!
>
> I would like to know how the proposal handles zonefile updates, assume
> that
> my program start and then a while later there is a new zonefile, how do I
> tell the library that it need to rereaad it?
>
> If load_time_zone always rereads the zonefile then I think that should be
> spelled out.
>
> /MF
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ca93afc7-b470-4e0c-a087-8f31c5baf6d3%40isocpp.org.

------=_Part_1804_1375990975.1455919466632
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for all the discussion here, folks. Now that I&#39;=
ve read this thread, I&#39;d like to quickly reiterate that whether or not =
and how the data is reloaded is not a critical part of the API. The fundame=
ntal conceptual model about how users should think about time zones should =
not be affected by this decision. However, you&#39;ve all raised good point=
s that should be discussed, so I will flesh out a new section in my doc lis=
ting various options, and I&#39;ll upload that draft to the wiki.<div><br><=
/div><div>I will also be at the Jacksonville meeting in person and I look f=
orward to discussing this further.</div><div><br></div><div>Thank you.</div=
><div>Greg<br><br>On Friday, February 19, 2016 at 3:16:58 AM UTC-5, Magnus =
Fromreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi!
<br>
<br>I would like to know how the proposal handles zonefile updates, assume =
that
<br>my program start and then a while later there is a new zonefile, how do=
 I
<br>tell the library that it need to rereaad it?
<br>
<br>If load_time_zone always rereads the zonefile then I think that should =
be
<br>spelled out.
<br>
<br>/MF
<br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ca93afc7-b470-4e0c-a087-8f31c5baf6d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ca93afc7-b470-4e0c-a087-8f31c5baf6d3=
%40isocpp.org</a>.<br />

------=_Part_1804_1375990975.1455919466632--
------=_Part_1803_879234366.1455919466632--

.

On 2016-02-19 16:48, Magnus Fromreide wrote:
> From your discussion I do get the feeling that you are all assuming that =
once
> the library reloads the database all existing time_zone objects are
> automatically updated, otherwise, how will the automatic updating tell th=
e
> application that it have to fetch new time_zone instances? If that is the
> case then how does that interact with multithreading?

Are you requiring that time conversions are thread safe (i.e. can use
the same object instance in multiple threads concurrently)? (Is that
really a critical design feature? Even if 'yes', a r/w mutex or
thread-local data could still deal with the problems.)

I'm not sure that changes things materially... when you ask the TZ
object to do a time conversion, or for TZ info, it could check how old
its TZ info is, and check if it needs to be updated. (I assume updating
does not introduce any thread safety issues that don't exist creating it
in the first place, i.e. they've been dealt with already.)

If you can reliably know when the DB changes, you could have an atomic
counter that tracks the last refresh, and the TZ instance could just
check its own "last update stamp" against that; a simple and normally
unlocked fetch and compare. (Then, if it *did* change, things get
expensive, but if so, you "need" to pay that cost.)

> Could one not imagine a method on the library
>=20
> bool bikeshed(); // ok, maybe "reload_time_zone" is a better name
>=20
> which the user could call periodically if they are interested in getting
> updates and which returns true if the database is updated and false other=
wise.

I can imagine that such a method might be impossible (or at least very,
very difficult / expensive) to implement.

OTOH, this is what I meant about implementation considerations :-). If
automagic refresh is impractical, then manual refresh may be the way to go.

That said, I'm less concerned about long-lived objects retaining bad
state, so long as newly created ones aren't using excessively stale
data. My impression from the start of this thread was that the original
design would "lock in" the TZ data once the process starts and would
never be able to update it without restarting the process. *That* is a
problem. "Requiring" that TZ object instances are not very long lived is
less of a problem.

Related, you might consider having a split API; one set of methods to
operate on cached data without checking if the cache is stale (in case
consistent performance is critical), and one to implicitly check first.

(Heh... we're dealing with the first of the Two Hard Problems in
Programming=C2=B9.)

(=C2=B9 cache invalidation, naming things, and off-by-one errors)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/na84el%247at%241%40ger.gmane.org.

.

On 2016-02-19 17:04, 'Greg Miller' via ISO C++ Standard - Future
Proposals wrote:
> Thanks for all the discussion here, folks. Now that I've read this thread=
,=20
> I'd like to quickly reiterate that whether or not and how the data is=20
> reloaded is not a critical part of the API.

It... sort of is. If you ignore the problem (and *this may be TRTTD!*),
you can just assume that the implementation will prevent staleness, and
chalk it up to implementation details / QoI. In this sense, I actually
think the original version of the paper=C2=B9 is okay=C2=B2. If, OTOH, you
*specify* that the data is cached, *and* don't provide for how that
cache is expired, then you've codified a broken design.

(=C2=B9 Caveat: I skimmed it; I didn't read it thoroughly.)

(=C2=B2 To be specific: the change=C2=B3 you made is *not* okay.)

(=C2=B3
https://github.com/devjgm/papers/commit/873b504e52f2f9038a0efe0460eb6d0c2e4=
24921)

See also my most recent reply to Magnus; depending on how you handle
this, it *can* have a significant impact on the API. (While I have a
*preference* how I'd like to see this issue handled, I really don't care
just so long as it *can* be handled.)

> The fundamental conceptual model about how users should think about
> time zones should not be affected by this decision.

That said, there is truth here also.

> However, you've all raised good points that should be discussed, so I
> will flesh out a new section in my doc listing various options, and
> I'll upload that draft to the wiki.

(BTW, where is this wiki?)

> I will also be at the Jacksonville meeting in person and I look forward t=
o=20
> discussing this further.

Me too; I hope I will be able to catch this discussion :-).

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/na84ru%24dv8%241%40ger.gmane.org.

.

Here is one example of how the timezone database =E2=80=9Creload=E2=80=9D f=
unctionality might work:

http://howardhinnant.github.io/tz.html#ThreadSafety

This is not a proposal.  But this is an existing library with a small (but =
enthusiastic) following.  For this library, the design decision was made le=
aning towards =E2=80=9Cdon=E2=80=99t pay for it if you don=E2=80=99t use it=
..=E2=80=9D  This puts more of the burden on the client who needs =E2=80=9Cr=
eload functionality=E2=80=9D.

I=E2=80=99m drawing attention to this API as a straw man for how such funct=
ionality might look like, should it be incorporated into the C++ standard. =
 Having a straw man to start from might spark good ideas from others which =
might improve upon this straw man.

Howard

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/51636F6A-C824-41AB-B338-4ECA963AD9AF%40gmail.com=
..

.

I think time_zone objects that change (ie update) in the middle of a calcul=
ation are a bad idea.=C2=A0

I don't have an answer/solution; I'm OK with the DB watching for updates an=
d informing me or automatically updating and marking items as stale or some=
thing, but moving the rug underneath me is typically bad.=C2=A0

Unless the API somehow makes it glaringly obvious that it could happen at a=
ny time. And 'glaringly obvious' must be better than just 'documented'.=C2=
=A0



Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Matthew Woehlke
Sent: Friday, February 19, 2016 5:20 PM
To: std-proposals@isocpp.org
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] Re: On p0216r0 (A timezone library)

On 2016-02-19 16:48, Magnus Fromreide wrote:
> From your discussion I do get the feeling that you are all assuming that =
once
> the library reloads the database all existing time_zone objects are
> automatically updated, otherwise, how will the automatic updating tell th=
e
> application that it have to fetch new time_zone instances? If that is the
> case then how does that interact with multithreading?

Are you requiring that time conversions are thread safe (i.e. can use
the same object instance in multiple threads concurrently)? (Is that
really a critical design feature? Even if 'yes', a r/w mutex or
thread-local data could still deal with the problems.)

I'm not sure that changes things materially... when you ask the TZ
object to do a time conversion, or for TZ info, it could check how old
its TZ info is, and check if it needs to be updated. (I assume updating
does not introduce any thread safety issues that don't exist creating it
in the first place, i.e. they've been dealt with already.)

If you can reliably know when the DB changes, you could have an atomic
counter that tracks the last refresh, and the TZ instance could just
check its own "last update stamp" against that; a simple and normally
unlocked fetch and compare. (Then, if it *did* change, things get
expensive, but if so, you "need" to pay that cost.)

> Could one not imagine a method on the library
>=20
> bool bikeshed(); // ok, maybe "reload_time_zone" is a better name
>=20
> which the user could call periodically if they are interested in getting
> updates and which returns true if the database is updated and false other=
wise.

I can imagine that such a method might be impossible (or at least very,
very difficult / expensive) to implement.

OTOH, this is what I meant about implementation considerations :-). If
automagic refresh is impractical, then manual refresh may be the way to go.

That said, I'm less concerned about long-lived objects retaining bad
state, so long as newly created ones aren't using excessively stale
data. My impression from the start of this thread was that the original
design would "lock in" the TZ data once the process starts and would
never be able to update it without restarting the process. *That* is a
problem. "Requiring" that TZ object instances are not very long lived is
less of a problem.

Related, you might consider having a split API; one set of methods to
operate on cached data without checking if the cache is stale (in case
consistent performance is critical), and one to implicitly check first.

(Heh... we're dealing with the first of the Two Hard Problems in
Programming=C2=B9.)

(=C2=B9 cache invalidation, naming things, and off-by-one errors)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/na84el%247at%241%40ger.gmane.org.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160219224350.4898897.44110.5204%40gmail.com.

.

------=_Part_2760_750008231.1456282000216
Content-Type: multipart/alternative;
 boundary="----=_Part_2761_1039142408.1456282000217"

------=_Part_2761_1039142408.1456282000217
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks again for the comments. I've added two sections to the document=20
titled "Thread Safety" and "Data Freshness" that should cover much of what=
=20
was discussed here. The current doc in github is=20
at https://github.com/devjgm/papers/blob/master/d0216r1.md.

I'll be sure to upload an html version named d0216r1.html to the wiki as=20
Jens suggested before Jacksonville.

Thanks.

On Friday, February 19, 2016 at 5:43:55 PM UTC-5, Tony V E wrote:
>
> I think time_zone objects that change (ie update) in the middle of a=20
> calculation are a bad idea. =20
>
> I don't have an answer/solution; I'm OK with the DB watching for updates=
=20
> and informing me or automatically updating and marking items as stale or=
=20
> something, but moving the rug underneath me is typically bad. =20
>
> Unless the API somehow makes it glaringly obvious that it could happen at=
=20
> any time. And 'glaringly obvious' must be better than just 'documented'. =
=20
>
>
>
> Sent from my BlackBerry portable Babbage Device=20
>   Original Message  =20
> From: Matthew Woehlke=20
> Sent: Friday, February 19, 2016 5:20 PM=20
> To: std-pr...@isocpp.org <javascript:>=20
> Reply To: std-pr...@isocpp.org <javascript:>=20
> Subject: [std-proposals] Re: On p0216r0 (A timezone library)=20
>
> On 2016-02-19 16:48, Magnus Fromreide wrote:=20
> > From your discussion I do get the feeling that you are all assuming tha=
t=20
> once=20
> > the library reloads the database all existing time_zone objects are=20
> > automatically updated, otherwise, how will the automatic updating tell=
=20
> the=20
> > application that it have to fetch new time_zone instances? If that is=
=20
> the=20
> > case then how does that interact with multithreading?=20
>
> Are you requiring that time conversions are thread safe (i.e. can use=20
> the same object instance in multiple threads concurrently)? (Is that=20
> really a critical design feature? Even if 'yes', a r/w mutex or=20
> thread-local data could still deal with the problems.)=20
>
> I'm not sure that changes things materially... when you ask the TZ=20
> object to do a time conversion, or for TZ info, it could check how old=20
> its TZ info is, and check if it needs to be updated. (I assume updating=
=20
> does not introduce any thread safety issues that don't exist creating it=
=20
> in the first place, i.e. they've been dealt with already.)=20
>
> If you can reliably know when the DB changes, you could have an atomic=20
> counter that tracks the last refresh, and the TZ instance could just=20
> check its own "last update stamp" against that; a simple and normally=20
> unlocked fetch and compare. (Then, if it *did* change, things get=20
> expensive, but if so, you "need" to pay that cost.)=20
>
> > Could one not imagine a method on the library=20
> >=20
> > bool bikeshed(); // ok, maybe "reload_time_zone" is a better name=20
> >=20
> > which the user could call periodically if they are interested in gettin=
g=20
> > updates and which returns true if the database is updated and false=20
> otherwise.=20
>
> I can imagine that such a method might be impossible (or at least very,=
=20
> very difficult / expensive) to implement.=20
>
> OTOH, this is what I meant about implementation considerations :-). If=20
> automagic refresh is impractical, then manual refresh may be the way to=
=20
> go.=20
>
> That said, I'm less concerned about long-lived objects retaining bad=20
> state, so long as newly created ones aren't using excessively stale=20
> data. My impression from the start of this thread was that the original=
=20
> design would "lock in" the TZ data once the process starts and would=20
> never be able to update it without restarting the process. *That* is a=20
> problem. "Requiring" that TZ object instances are not very long lived is=
=20
> less of a problem.=20
>
> Related, you might consider having a split API; one set of methods to=20
> operate on cached data without checking if the cache is stale (in case=20
> consistent performance is critical), and one to implicitly check first.=
=20
>
> (Heh... we're dealing with the first of the Two Hard Problems in=20
> Programming=C2=B9.)=20
>
> (=C2=B9 cache invalidation, naming things, and off-by-one errors)=20
>
> --=20
> Matthew=20
>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "ISO C++ Standard - Future Proposals" group.=20
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to std-proposal...@isocpp.org <javascript:>.=20
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.=
=20
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/na84el%247at=
%241%40ger.gmane.org.=20
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/30a848be-c836-4592-a762-c725f5b83ce7%40isocpp.or=
g.

------=_Part_2761_1039142408.1456282000217
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks again for the comments. I&#39;ve added two sections=
 to the document titled &quot;Thread Safety&quot; and &quot;Data Freshness&=
quot; that should cover much of what was discussed here. The current doc in=
 github is at=C2=A0https://github.com/devjgm/papers/blob/master/d0216r1.md.=
<div><br></div><div>I&#39;ll be sure to upload an html version named d0216r=
1.html to the wiki as Jens suggested before Jacksonville.</div><div><br></d=
iv><div>Thanks.</div><br>On Friday, February 19, 2016 at 5:43:55 PM UTC-5, =
Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I think time_zo=
ne objects that change (ie update) in the middle of a calculation are a bad=
 idea.=C2=A0
<br>
<br>I don&#39;t have an answer/solution; I&#39;m OK with the DB watching fo=
r updates and informing me or automatically updating and marking items as s=
tale or something, but moving the rug underneath me is typically bad.=C2=A0
<br>
<br>Unless the API somehow makes it glaringly obvious that it could happen =
at any time. And &#39;glaringly obvious&#39; must be better than just &#39;=
documented&#39;.=C2=A0
<br>
<br>
<br>
<br>Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr>portable=C2=A0Babbage=
=C2=A0Device
<br>=C2=A0 Original Message =C2=A0
<br>From: Matthew Woehlke
<br>Sent: Friday, February 19, 2016 5:20 PM
<br>To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
6m1k7F3eAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-pr...@isocpp.org</a>
<br>Reply To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"6m1k7F3eAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">std-pr...@isocpp.org</a>
<br>Subject: [std-proposals] Re: On p0216r0 (A timezone library)
<br>
<br>On 2016-02-19 16:48, Magnus Fromreide wrote:
<br>&gt; From your discussion I do get the feeling that you are all assumin=
g that once
<br>&gt; the library reloads the database all existing time_zone objects ar=
e
<br>&gt; automatically updated, otherwise, how will the automatic updating =
tell the
<br>&gt; application that it have to fetch new time_zone instances? If that=
 is the
<br>&gt; case then how does that interact with multithreading?
<br>
<br>Are you requiring that time conversions are thread safe (i.e. can use
<br>the same object instance in multiple threads concurrently)? (Is that
<br>really a critical design feature? Even if &#39;yes&#39;, a r/w mutex or
<br>thread-local data could still deal with the problems.)
<br>
<br>I&#39;m not sure that changes things materially... when you ask the TZ
<br>object to do a time conversion, or for TZ info, it could check how old
<br>its TZ info is, and check if it needs to be updated. (I assume updating
<br>does not introduce any thread safety issues that don&#39;t exist creati=
ng it
<br>in the first place, i.e. they&#39;ve been dealt with already.)
<br>
<br>If you can reliably know when the DB changes, you could have an atomic
<br>counter that tracks the last refresh, and the TZ instance could just
<br>check its own &quot;last update stamp&quot; against that; a simple and =
normally
<br>unlocked fetch and compare. (Then, if it *did* change, things get
<br>expensive, but if so, you &quot;need&quot; to pay that cost.)
<br>
<br>&gt; Could one not imagine a method on the library
<br>&gt;=20
<br>&gt; bool bikeshed(); // ok, maybe &quot;reload_time_zone&quot; is a be=
tter name
<br>&gt;=20
<br>&gt; which the user could call periodically if they are interested in g=
etting
<br>&gt; updates and which returns true if the database is updated and fals=
e otherwise.
<br>
<br>I can imagine that such a method might be impossible (or at least very,
<br>very difficult / expensive) to implement.
<br>
<br>OTOH, this is what I meant about implementation considerations :-). If
<br>automagic refresh is impractical, then manual refresh may be the way to=
 go.
<br>
<br>That said, I&#39;m less concerned about long-lived objects retaining ba=
d
<br>state, so long as newly created ones aren&#39;t using excessively stale
<br>data. My impression from the start of this thread was that the original
<br>design would &quot;lock in&quot; the TZ data once the process starts an=
d would
<br>never be able to update it without restarting the process. *That* is a
<br>problem. &quot;Requiring&quot; that TZ object instances are not very lo=
ng lived is
<br>less of a problem.
<br>
<br>Related, you might consider having a split API; one set of methods to
<br>operate on cached data without checking if the cache is stale (in case
<br>consistent performance is critical), and one to implicitly check first.
<br>
<br>(Heh... we&#39;re dealing with the first of the Two Hard Problems in
<br>Programming=C2=B9.)
<br>
<br>(=C2=B9 cache invalidation, naming things, and off-by-one errors)
<br>
<br>--=20
<br>Matthew
<br>
<br>--=20
<br>You received this message because you are subscribed to the Google Grou=
ps &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>To unsubscribe from this group and stop receiving emails from it, send =
an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"6m1k7F3eAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">std-proposal...@<wbr>isocpp.org</a>.
<br>To post to this group, send email to <a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"6m1k7F3eAAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>To view this discussion on the web visit <a href=3D"https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/na84el%247at%241%40ger.gmane.org"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/d/msgid/std-proposals/na84el%247at%241%40ge=
r.gmane.org&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/na84el%247at%241%40ger.gmane.o=
rg&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/s=
td-<wbr>proposals/na84el%247at%241%<wbr>40ger.gmane.org</a>.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/30a848be-c836-4592-a762-c725f5b83ce7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/30a848be-c836-4592-a762-c725f5b83ce7=
%40isocpp.org</a>.<br />

------=_Part_2761_1039142408.1456282000217--
------=_Part_2760_750008231.1456282000216--

.