Re: 2017-03-06- UTC, TImeZone, DayLight Saving Shifts, Enconding

Hello,

On 18.03.2017 16:18, Joe Touch wrote:
> On 3/18/2017 4:54 AM, Walter H. wrote:
>> On 07.03.2017 17:33, Joe Touch wrote:
>>>
>>> There are trade-offs, certainly. The issue isn't just what format you
>>> can implement; it's what format you use as your *primary* encoding,
>>> e.g., when storing time stamps in a large database. Pick the wrong
>>> one and you spend a lot of cycles converting. No single format avoids
>>> conversions for three common uses:
>>>
>>> - to compute deltas or establish strict ordering (UT, now called TA)
>>> - to interact with official government times (UTC is the standard)
>>> - to present information to a human user conveniently (people want
>>> localtime)
>>>
>> the 3rd point is the biggest problem at all, nearly no software does
>> it correct ...
>>
>> a day begins at 00:00:00 and ends at 23:59:59
>> (it is really a heavy thing when counting starts at zero ...)
> Well, here in the US we start at 12:00am and never use zero values.
then the end is 11:59 pm and never 12:00am (if you want it without seconds)
or 11:59:59pm (if you want it with seconds)
>> and now look at e.g. the calendar of Microsoft Outlook and look for
>> the beginning and ending of a celebration day ...
> The begin and end of a workday are configurable parameters within
> Outlook. All-day events start at the beginning of a day (12am for
> 12-hour clocks, 00:00 for 24-hour). This is what should be expected.
I  was not talking about a workday ..., I was talking about the general 
problem
the last day of the year ends at 11:59 pm and not 12:00 am - as this is 
the time the next day starts;

by the way 12:00 pm is not defined, as the day has only 24 hours = 1440 
minutes = 86400 seconds
as I said it is a very difficult thing when counting beginns at zero ...
> Can you explain your concern?

talk about sophisticated things, after the basics have been understood ...

Greetings