bugGNUstep - Bugs: bug #33455, Time zone issue on Linux systems...

Group
 
 

bug #33455: Time zone issue on Linux systems running in the UK

Submitter:  Wolfgang Lux <wlux>
Submitted:  Wed 01 Jun 2011 01:01:49 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Change Request Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 18 Jun 2011 01:10:33 PM UTC, comment #8: 

I guess this is fixed ... at least we now have special case heuristics to infer the timezone on debian and redhat if it's not set.

Richard Frith-Macdonald <CaS>
Group Member
Thu 02 Jun 2011 10:44:21 AM UTC, comment #7: 


> > could just try and read the time zone data from /etc/localtime
> > if it exists?
>
> Yes, that would give us working timezone offsets (so we could
> display the correct date and hours/minutes), but it wouldn't
> give us the timezone name ... so use/display of the zone name
> would be broken.


Sure. I was just suggesting to use this as a fallback before resorting to tzname. This function seems to return only time zone abbreviations as well (probably the ones contained in /etc/localtime), so we aren't able to display proper time zone names in this case either. But at least we would be using the correct timezone offsets.

> I've hacked in code for debian (to look in /etc/timezone) and
> redhat/centos (to look in /etc/sysconfig/clock) for the name
> of the timezone


Well, thanks, this at least solves my original problem.

Wolfgang Lux <wlux>
Thu 02 Jun 2011 08:12:11 AM UTC, comment #6: 


> could just try and read the time zone data from /etc/localtime if it exists?


Yes, that would give us working timezone offsets (so we could display the correct date and hours/minutes), but it wouldn't give us the timezone name ... so use/display of the zone name would be broken.

I've hacked in code for debian (to look in /etc/timezone) and redhat/centos (to look in /etc/sysconfig/clock) for the name of the timezone ... of course all this is horribly system dependent because there seems to be no portable mechanism to obtain full timezone info.  The lack of a standard (and the need for OpenStep compatibility) is the historical reason why gnustep-base provides its own timezone data.

Richard Frith-Macdonald <CaS>
Group Member
Wed 01 Jun 2011 04:16:20 PM UTC, comment #5: 


> Yes, if you install by building from source the
> HOWTo's/documentation tell you to set the default/env variable,
> and if you install from a package, the packager should have done
> that for you.


Who reads installation documentation :-)
And the packager is of no help once you change the time zone after installing the package (e.g., because you move to another country).

> I suppose it would be possible to enumerate the list of
> available timezones, and look for one whose standard and
> daylight times match tzname[0] and tzname[1] and use the
> first match found ... I don't know if that would be
> completely reliable (there could be timezones which use
> the same pair of offsets but different dates for changing
> between them for instance), but it would be a better guess
> than at present. However, it could be slow as we might have
> to load in the data files for all the time zones.


Yes, I don't like the idea of scanning for a match either (I've considered running something like sh -c "cd /usr/share/zoneinfo; for f in `find * -type f`; do cmp -s $f /etc/localtime && echo $f; done", but not seriously).

However, before giving up or falling back to tzset(), +systemTimeZone could just try and read the time zone data from /etc/localtime if it exists?

Wolfgang Lux <wlux>
Wed 01 Jun 2011 03:43:02 PM UTC, comment #4: 


> So the question is what means properly installed.
> I know I can set 'Local Time Zone' in NSGlobalDefaults
> or even set up a file somewhere deep in the gnustep-base
> library's resources (which I'd like to refrain from doing,
> since that file has to be recreated whenever -base is updated to a new version),


Yes, if you install by building from source the HOWTo's/documentation tell you to set the default/env variable, and if you install from a package, the packager should have done that for you.

> but I'd prefer not having to perform such additional post installation steps.


Me too ... but nobody's come up with a reliable way to do it :-(

> NSTimeZone uses the information provided by tzset. In particular, this is
> tzname[0] = "GMT"
> tzname[1] = "BST"
> timezone = 0
> daylight = 1


Unfortunately tzset doesn't tell you what time zone the system uses, unless 'daylight=0', in which case tzname[0] should hold the zone name (though even then it could be an ambiguous abbreviation).

I suppose it would be possible to enumerate the list of available timezones, and look for one whose standard and daylight times match tzname[0] and tzname[1] and use the first match found ... I don't know if that would be completely reliable (there could be timezones which use the same pair of offsets but different dates for changing between them for instance), but it would be a better guess than at present.  However, it could be slow as we might have to load in the data files for all the time zones.

Richard Frith-Macdonald <CaS>
Group Member
Wed 01 Jun 2011 03:02:59 PM UTC, comment #3: 


> It's not so much a bug as an incorrectly installed system ...
> base tries to guess the timezone if it's not properly installed,


So the question is what means properly installed. I know I can set 'Local Time Zone' in NSGlobalDefaults or even set up a file somewhere deep in the gnustep-base library's resources (which I'd like to refrain from doing, since that file has to be recreated whenever -base is updated to a new version), but I'd prefer not having to perform such additional post installation steps.

> IIRC gnustep-base defaults to GMT/UCT/UTC/Zulu (all mean the
> same) if it fails to guess the timezone from the information
> the operating system makes available.


While that is true, I doesn't apply to the systems in question. NSTimeZone uses the information provided by tzset. In particular, this is
  tzname[0] = "GMT"
  tzname[1] = "BST"
  timezone = 0
  daylight = 1

Wolfgang Lux <wlux>
Wed 01 Jun 2011 02:15:02 PM UTC, comment #2: 

It's not so much a bug as an incorrectly installed system ... base tries to guess the timezone if it's not properly installed, and it's not guessing it correctly in this particular case.  However, it would be good to make the guess more reliable if possible.

> Apparently, there is an inherent ambiguity in the time zone abbreviation "GMT",
> which can denote standard time (nowadays known as UCT) and the standard
> UK time zone.


This is not the case (GMT unambiguously denotes standard time), though many of the timezone abbreviations are ambiguous.

The UK time zone is WET (western european time).
In the winter WET is the same as GMT (greenwich mean time)
In the summer, WET is the same as BST (british summer time)

IIRC gnustep-base defaults to GMT/UCT/UTC/Zulu (all mean the same) if it fails to guess the timezone from the information the operating system makes available.


Richard Frith-Macdonald <CaS>
Group Member
Wed 01 Jun 2011 01:33:42 PM UTC, comment #1: 

Some additional info on this issue:

The Linux systems copy the time zone file Europe/London from /usr/share/zoneinfo to /etc/localtime when the time zone is set rather than creating a soft link. This breaks the logic in NSTimeZone +systemTimeZone to deduce the full time zone name from the link.

Apparently, there is an inherent ambiguity in the time zone abbreviation "GMT", which can denote standard time (nowadays known as UCT) and the standard UK time zone. [[NSTimeZone alloc] initWithName: @"GMT"] apparently decides for UCT=GMT+0000, but NSTimeZone +systemTimeZone should do better when falling back to querying tzname by noting that the daylight global is non-zero (see man tzset).

Wolfgang Lux <wlux>
Wed 01 Jun 2011 01:01:49 PM UTC, original submission:  

On a CentOS or Debian system configured to use Europe/London as its time zone, NSTimeZone does not recognize when daylight saving time is in effect. E.g., the current time (using [NSCalendarTime date]) is reported as "2011-06-01 12:37:41 +0000", but should be reported as "2011-06-01 13:37:41 +0100". The problem likely is that the time zone reported by [NSTimeZone systemTimeZone] is "GMT+0000", for which [[NSTimeZone systemTime] isDaylightSavingTime] returns NO.

This problem doesn't appear for other countries, e.g., for Europe/Lisbon I get "2011-06-01 13:41:56 +0100". I also do not see the problem when running GNUstep base under OS X.


Wolfgang Lux <wlux>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by wlux (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-06-18 CaS StatusNone Fixed
        Open/ClosedOpen Closed
    2011-06-01 CaS Item GroupBug Change Request

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code