On Wed, Oct 30, 2019 at 2:39 PM Beraldo Leal <bl...@redhat.com> wrote:
>
> On Wed, Oct 30, 2019 at 6:06 AM Amador Pahim <ama...@pahim.org> wrote:
> > But you can respect the timezone AND avoid ambiguity with "2019-12-01
> > 09:02:52+03:00".
> > As a user, if the timezone is a problem, I would set up my system to
> > GMT. If parsing is a problem, I'd setup avocado to "epoch".
> > What I fail to see is the use case for ISO-8601 in UTC.
>
> Delegating these settings to the user is an option to consider, for sure.
> But I confess that I have my doubts in this specific case.
>
> If the user does not type %Z or %z in the format variable, the information
> will
> be saved without a timezone, which might be a problem.
>
> On the other hand, if it is correctly specified (by the user or by default
> value),
> we can have multiple 'datetimes' with different time zones (for the
> particular cases where
> a DST period starts or ends).
>
> See the example below:
>
> ---
> $> fmt = "%Y-%m-%dT%H:%M:%S %Z"
> $> tz = timezone('America/Sao_Paulo')
> $> dt1 = tz.localize(datetime(2018, 2, 16, 23, 1, 0))
> $> dt2 = tz.localize(datetime(2018, 2, 18, 1, 40, 0))
> $> dt1.strftime(fmt)
> '2018-02-16T23:01:00 -02' # Before Daylight Saving Time Ended
> $> dt2.strftime(fmt)
> '2018-02-18T01:40:00 -03' # After Daylight Saving Time Ended
> ---
What's the problem with that?
2018-02-16T23:01:00 -03
and
2018-02-16T23:01:00 -02
Are 1h apart that is pretty clear...
If users define a custom formatter, without the %z in it, well, they
probably want that.
>
> Also, we will have to decide if the user will choose the TZ from the config
> file,
> or if we will try to guess from the system settings.
No need to try to guess or to have it set by the user...
time.localtime() will give you that.
