2012/2/6 David T. Lewis <lewis at mail.msen.com>:
> On Mon, Feb 06, 2012 at 12:18:07PM +0100, Nicolas Cellier wrote:
>> OK, I understand.
>> The vm (primSecondsClock) is answering number of seconds since
>>
>> January 1, 1901 00h00 Local Time
>>
>> Or more exactly,
>> seconds_ellapsed_since_January_1_1901_00h00_UTC -
>> current_local_time_offset_in_seconds_to_utc
>>
>> So the image must reflect this...
>
> Yes.
>
>
>> I noticed that the vm has to answer a LargePositiveInteger (Time
>> primSecondsClock class), which I find a bit suboptimal...
>> I browsed all the DateAndTime now, secondsWhenClockTicks,
>> initializeOffsets, milliSecondsSinceMidnight and found the code
>> - complex (I particularly don't like MilliSecondOffset :=
>> MilliSecondOffset + (SmallInteger maxVal // 2) + 1 in
>> #milliSecondsSinceMidnight)
>> - optimistic or brittle (what guaranty against preemption by other
>> process #secondsWhenClockTicks has ?)
>>
>> If we want the underlying operating system to handle time zone and DST for us,
>> then it would be more convenient to have a vm primitive filling an
>> Array
>>     with: julianDayNumberInOperatingSystemLocalTime
>>     with: secondsSinceMidnightLocalTime "Wall clock time"
>>     with: subSecondsFraction
>>     with: localTimeOffset
>
> This still leaves us with the problem of converting from local time to UTC
> in the image, which is problematic during a daylight savings time transition
> (two values of the UTC seconds clock map to the same local seconds clock
> value, which one is correct?). It is better to use UTC because translating
> from UTC to local seconds is unambiguous.
>

No, if the primitive also fill the localOffset, then you'll get twice
the same wallClockTime, but with a different localOffset.
In this case, conversion to UTC is trivial.

>>
>> If we want, we could have a second primitive for UTC, but this is redundant:
>> Array
>>     with: julianDayNumberUTC
>>     with: secondsSinceMidnightUTC
>>     with: subSecondsFraction
>
> A suitable primitive is currently implemented in the standard interpreter VM:
>
> primitiveUtcWithOffset
>        "Answer an array with UTC microseconds since the Posix epoch and
>        the current seconds offset from GMT in the local time zone.
>        This is a named (not numbered) primitive in the null module (ie the VM)"
>
> If you want to experiment with it, add the following method to the class side of Time:
>
> primUtcWithOffset
>        "Invoke the primitive implemented in recent Squeak VMs.
>        Answer an array with UTC microseconds since the Posix epoch and
>        the current seconds offset from GMT in the local time zone."
>
>        "Time primUtcWithOffset"
>
>        <primitive: 'primitiveUtcWithOffset'>
>
> I think it is best to leave the complexity of translating to julian
> day, seconds, etc on the image side rather that put it in the VM, unless
> there is a measurable performance advantage to putting it in the VM.
>

I don't know. The julianDayNumber sounds like assembler to me ;)
	
	p := (monthIndex - 14) quo: 12.
	q := year + 4800 + p.
	r := monthIndex - 2 - (12 * p).
	s := (year + 4900 + p) quo: 100.

	julianDayNumber :=
 		( (1461 * q) quo: 4 ) +
			( (367 * r) quo: 12 ) -
 				( (3 * s) quo: 4 ) +
 					( day - 32075 ).

Which date would overflow? Not that soon I guess.

Also, I'm not sure that duplicating the time zone and DST handling in
the image is a good idea.
What advantage over OS would this provide?

Nicolas

> I'll note also that the primitiveUtcWithOffset approach was originally
> proposed by Lex Spoon about ten years ago, and has been periodically
> debated and discussed ever since. My view is that Lex's approach provides
> the best overall balance of conceptual clarity (well defined and documented
> on Wikipedia) and implementation (fast, easy to implement on any platform,
> minimal logic required in the support code). If (and this is a big "if")
> we are going to go to the trouble of changing the image to use UTC as
> a basis rather than local time, then this approach is the right way to
> do it.
>
>
>> As for leap seconds, they seem rather impractical to me, because:
>> - they exist for very few years
>> - they are irregular and can only be represented in a sort of database
>> - they are rather unpredictable
>> IMHO, only astronomical apps would use such information.
>
> I agree. For any reasonable use case, it is sufficient to let the operating
> system decide whether or not to consider leap seconds when we ask the
> VM for "seconds since the epoch".
>
>

SNIP