On Tue, Mar 22, 2011 at 11:47:53PM +0100, Sascha Silbe wrote: > Excerpts from James Cameron's message of Mon Mar 21 04:09:27 +0100 2011: > > - remove GMT offsets as useless, since GMT tracks UTC and this is not > > expected to change, > > > > - fix #2195 by translating from ISO 8601 to POSIX.1 format, by > > reversing the sign, > > > > - increase UTC timezone coverage for Kiribati and Tonga. > > Thanks for the patch! It's a good start, but unfortunately not enough. > POSIX defines TZ as "std offset dst offset, rule" [1], ...
No, according to [1] only the "std offset" form is required, the remaining fields are optional. Therefore my patch is correct. > with std and dst being the name of the _local_ time zone (for standard > resp. daylight savings time). > Even after your patch Sugar always claims the local time zone to be > UTC which is clearly incorrect (for non-zero offsets). Yes, the system will claim the local time zone to be UTC. This is unchanged from before the patch. The patch was not intended to fix this. Do you consider it a problem? It is not mentioned in #2195. Would you like a bug raised in trac? It will only affect applications or activites that use TZ, and I don't have a list of those. I cannot assess the impact. I see this as a separate problem to the problem addressed by my patch, and I don't think it should prevent my patch from being accepted. The options to fix this separate problem are: 1. add a text field for entering the time zone name, since we cannot be sure that a local time zone will exist in zone.tab or Etc, 2. use an indicative value, such as TZ="<none>-11", which results in "none" as the time zone name shown by date(1), 3. use the "TZ=:Etc/GMT-11" style mentioned by Daniel, which results in "GMT-11" as the time zone name shown by date(1), 4. remove the date time control panel and rely on the system timezone only. Out of interest, which of these will you adopt? > In the long term I'd like to get rid of this Sugar-specific control > panel and recycle something from Gnome. I don't think long term plans have any bearing. This is here and now. Unless this recycling is imminent, my patch should be accepted. > Short term an option might be to parse the > /usr/share/zoneinfo/zone.tab file. I don't understand what you mean. Can you please explain further? The code already reads zone.tab and uses the third field of non-comment lines. Is it that you mean reading of the geographical coordinates and displaying them graphically? This seems excessive for a control panel section that would rarely be used by children. > Probably too invasive for 0.92.x, though (but OLPC can cherry-pick > from master). When to accept my patch is not my concern. I don't think OLPC needs this patch accepted; for solar panel power logging we will direct testers to select the named time zone rather than the UTC offset time zones. The problem is too trivial and easily worked around to warrant any significant effort. > [1] > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html#tag_08_03 -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
