octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53539] GUI file browser date stamps / editor


From: Lars Kindermann
Subject: [Octave-bug-tracker] [bug #53539] GUI file browser date stamps / editor script file appear modified when parsing date strings
Date: Sat, 12 Jan 2019 06:36:14 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Follow-up Comment #23, bug #53539 (project octave):

@Andrew: Setting TZ to UTC0 around strptime() was introduced due to a bug:
Converting a string into a tz structure in timezones with daylight saving
depends on the current daylight saving state, and gives strange results during
the hour where the clocks are turned back. Only in UTC0 strptime() just
literally converts the string elements into the fields of a tz structure
without fiddling around with daylight saving.

There is no way of asking libc's strptime() directly to use a specific
timnezone, it always retrieves TZ from the environment.  

If you look at the glibc sources of strptime() you see what is done there: It
just calls __strptime_internal. passing the current locale which includes the
current TZ: 


char * strptime (const char *buf, const char *format, struct tm *tm)
{
  return __strptime_internal (buf, format, tm, NULL, _NL_CURRENT_LOCALE);
}


So in glibc there *is* a function where UTC0 simply could be passed to, but
unfortunately it is declared as hidden. In glibc's time.h here is the
declaration:

   
/* strptime support.  */
extern char * __strptime_internal (const char *rp, const char *fmt,
                                   struct tm *tm, void *statep, locale_t
locparam) attribute_hidden;


If we could call that function directly from datevec.m instead of wrapping
strptime wtih setenv(TZ), everything would immediately be fine. Btw: A lot of
software is facing such problems, e.g. the timestamps of files shown in the
windows explorer change with daylight saving...  




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?53539>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]