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

Hi, Walter,

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.

> 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.

Can you explain your concern?


Received on Saturday, 18 March 2017 15:19:21 UTC