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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitted by:  Wolfgang Lux <wlux>
Submitted on:  Wed 01 Jun 2011 01:01:49 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: Change RequestStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission 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>
Project 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>
Project 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>
Project 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>
Project 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>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 18 Jun 2011 01:10:33 PM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 01 Jun 2011 02:15:02 PM UTCCaSItem GroupBug=>Change Request

    Back to the top


    Powered by Savane 3.1-cleanup1