I see useLocale, and it's false in standard Squeak 4.3.  Not sure how
but when I look at DateAndTime's 'LocalTimeZone' class var, it's as if
your fixed startup method ran because it says 'Local Time' and has the
correct offset.

> So, at the very least, anyone who needs correct UTC times must enable #useLocale. Better yet, we should switch to a more robust setup.

Well Chronology is robust, and it appears just flipping a default
setting would "fix" it anyway..?



On Fri, May 18, 2012 at 5:38 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 18.05.2012, at 03:44, David T. Lewis wrote:
>
>> On Thu, May 17, 2012 at 06:36:23PM -0700, Sean P. DeNigris wrote:
>>>
>>> David T. Lewis wrote
>>>>
>>>> it would be really nice to be able to simply refer people
>>>> to the relevant Wikipedia page, where the concepts are properly documented
>>>> and clearly explained.
>>>>
>>>
>>> If you decide to go with the Unix epoch, I made the changes (which ended up
>>> being minimal) in Pharo and all the relevant tests pass. The packages are in
>>> the Pharo inbox - Kernel-SeanDeNigris.1087, KernelTests-SeanDeNigris.406,
>>> Network-Mail-SeanDeNigris.11 & RecentSubmissions-SeanDeNigris.158
>>
>> Thanks!
>>
>> Dave
>
>
> We need to do *something*.
>
> I just discovered my vanilla Squeak image assumes the whole world lives in California summer time (UTC-7). Even though I fixed that a while ago.
>
> This is because the #useLocale preference is off by default, so the time zone does not get set at startup. (In Etoys, which relies on correct UTC time stamps in some environments, the preference is enabled by default).
>
> So for many, these two expressions return the wrong time:
>
>        DateAndTime now asUTC
>        DateAndTime now asUnixTime
>
> and even just
>
>        DateAndTime now
>
> is wrong because although it uses the correct local time, it has the wrong time zone.
>
> So, at the very least, anyone who needs correct UTC times must enable #useLocale. Better yet, we should switch to a more robust setup.
>
> - Bert -
>
>