On 15/02/16 09:07, Paul Eggert wrote:
Arthur David Olson wrote:
"LST" (Local Standard Time) (in some cases, in conjunction with "LDT") could used for all those (new) cases where an abbreviation isn't known.
This would be less useful for traditional time stamps. For example, the output of successive invocations of POSIX 'date' in the C locale in Astrakhan might look like this:
Tue Jul 1 12:31:27 LST 2014 Mon Feb 15 03:18:46 LST 2016 Sat Jul 1 23:51:21 LST 2017 Presume you meant LDT for July?
and information about the UT offset would be lost. In contrast, using +NN would case 'date' output to look like this:
Tue Jul 1 12:31:27 +04 2014 Mon Feb 15 03:18:46 +03 2016 Sat Jul 1 23:51:21 +04 2017
and the UT offset info would be available. The one thing I still find a major problem is the fact that dates which involve a daylight saving element are not easy to identify. The fact that we STILL only have a UT offset from the browser means that moving that Febuary meeting to April one has no idea if there should be an hour switch ... or not ... At least if the abbreviation can be identified as part of a DST pair one know to look up the switch dates. If there is no DST element, then +nn *IS* all that is needed? But perhaps an additional S or D if the offset involves a DST rule set?
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk