On Wed, Oct 30, 2019 at 10:39:02AM -0300, Beraldo Leal 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.
>
Right. It's important to get the data right from its inception. IMO,
it means either to always have a TZ, or to assume UTC. That rules out
localtime (with an implicit TZ) as a date/time format.
We have to keep in mind that running tests part of the same job on
machines in different TZs is a very real possiblity.
- Cleber.
> 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
> ---
>
> 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.
>
> --
> Beraldo Leal
> Senior Software Engineer, Virtualization Team
> Red Hat
