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

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 ...)
and now look at e.g. the calendar of Microsoft Outlook and look for the 
beginning and ending of a celebration day ...

Received on Saturday, 18 March 2017 11:55:22 UTC