Opened 14 years ago

Closed 9 years ago

#2195 closed defect (fixed)

Control panel, timezone incorrectly calculated

Reported by: tonyforster Owned by: anurag_seeta
Priority: High Milestone: Unspecified
Component: Sugar Version: Unspecified
Severity: Unspecified Keywords: dextrose
Cc: manu@…, quozl@… Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

Either a control panel error or a buggy datetime library
os373py

Melbourne is UTC+10
Selecting Australia/Melbourne calculates correctly
UTC+10 and GMT+10 give the wrong time for Melbourne
UTC-10 and GMT-10 give Melbourne time

Use the Clock activity
or Pippy
from datetime import datetime
print datetime.now()

Change History (11)

comment:1 Changed 14 years ago by seeta

  • Owner changed from tomeu to anurag_seeta
  • Status changed from new to assigned

comment:2 Changed 14 years ago by seeta

  • Cc manu@… added

comment:3 Changed 14 years ago by quozl

Once "UTC+10" is selected, the value "UTC+10" is placed in the TZ variable, and is present in Terminal on next restart:

% echo $TZ
UTC+10

However, this value does not give the desired result for the date command or using Pippy. The effect is reversed, as can be seen on the shell prompt:

% TZ=UTC date
Mon Sep 13 05:56:19
% TZ=UTC+1 date
Mon Sep 13 04:56:22

Therefore there is something strange about how libc is doing this. To compensate, Sugar should reverse the sign on these before setting the timezone.

Also, there are locations that use a UTC+13 and UTC+14 timezone, such as Tonga and Line Islands. Yet UTC+13 and UTC+14 are not offered by Sugar.

comment:5 Changed 10 years ago by tch

  • Priority changed from Unspecified by Maintainer to High

Looking at git log extensions/cpsection/datetime/model.py, there doesn't seem to be any change regarding this issue.

The sign issue is still present just as quozi explained above.

comment:6 Changed 9 years ago by SAMdroid

I tested this on my f20 computer and the bug is not there. the $TZ is like Australia/Sydney not GMT/UTC. I will text, but I think this is xo specific.

comment:7 Changed 9 years ago by SAMdroid

  • Cc quozl@… added
  • Resolution set to fixed
  • Status changed from assigned to closed

Tested on an XO4 with a SugarLabs 0.100.0 Image. This does not happen. It must of been fixed upstream, yay!

As for the issue with Tonga and Line Islands, that is an os issue. You need to add it to the timezone folder /usr/share/zoneinfo. The tzdata-2014g-1.fc20.noarch package provides these files. Maybe you should talk to them.

comment:8 Changed 9 years ago by quozl

  • Resolution fixed deleted
  • Status changed from closed to reopened

Perhaps you misunderstood the problem, Sam.

I've just tested on XO-4, using Sugar 0.102 on Fedora 20 in OLPC image 41003o4.

  • the original problem described by Tony Forster in the ticket summary, and the underlying problem in comment:3, still occurs,
  • the usage of UTC+n and UTC-n is relevant for any location where the date and time are not linked to geopolitical boundaries, such as at sea, in remote areas, or the polar regions,
  • removing this usage instead of fixing it is a possibility,
  • the restart offered by the control panel is not strictly necessary; as long as an activity is started after the change, the TZ environment variable is set correctly.

comment:9 Changed 9 years ago by godiard

We pushed the changes to the sugar repo, Sam can you confirm if is fixed and close this ticket?

comment:10 Changed 9 years ago by quozl

Where were the changes pushed? I cannot see any new commits in https://github.com/sugarlabs/sugar for the extensions/cpsection/datetime/ path.

comment:11 Changed 9 years ago by Sam Parkinson

  • Resolution set to fixed
  • Status changed from reopened to closed

Fix UTC time handeling, fixes #2195

Using the solution suggested by Sascha Silbe [1]. TL;DR "All of the
UTC+X UTC-X timezones could be translated into entries in
/usr/share/zoneinfo/Etc. For example, "UTC-5" would be converted to
TZ=:Etc/GMT+5"

Simmilar to Quozl's patch [2]. Quozl explains his patch as "translating
from ISO 8601 to POSIX.1 format, by reversing the sign"

[1]: http://lists.sugarlabs.org/archive/sugar-devel/2011-March/030532.html
[2]: http://lists.sugarlabs.org/archive/sugar-devel/2011-March/030497.html

Changeset: 4a4bc3097ae49cb70a50c2885006f7a09d30aae6

Note: See TracTickets for help on using tickets.