"Eric Ulevik" eau@fast.fujitsu.com.au writes:
The point is that the second primitive must take UTC value and time zone as input, and return the local time. Also note this is not a 1:1 map.
How not 1:1? Are there two local times that correspond to the same UTC time, or is it two UTC times that correspond to the same local time?
No matter how much I learn about time, there always seems to be more to learn.
From: Stan Heckman stan@stanheckman.com
"Eric Ulevik" eau@fast.fujitsu.com.au writes:
The point is that the second primitive must take UTC value and time zone
as
input, and return the local time. Also note this is not a 1:1 map.
How not 1:1? Are there two local times that correspond to the same UTC time, or is it two UTC times that correspond to the same local time?
Consider setting back the clock 1 hour at 2am.
Reading your clock every half hour: 0000 0030 0130 0200 0230 0200 0230 0300 0330 0400
The local time 0230 is repeated twice; it represents two different instants.
No matter how much I learn about time, there always seems to be more to learn.
Time is not overly complicated, but it's not as simple as most programmers think. The key is to use a sensible basis for measurement (eg. UTC). Perform all your calculations using this basis, and treat everything else as labelling rules (eg. local time).
A good example to consider is drawing charts with an x-axis as given above.
Everything you need, including code and up-to-date time zone data, can be found at ftp://elsie.nci.nih.gov/pub/
Regards,
Eric Ulevik
squeak-dev@lists.squeakfoundation.org
-
Eric Ulevik -
Stan Heckman