vw 7.7 support for Windows 2000

"Christian Haider"<[hidden email]> wrote:
I can't give you official support answer, only support can, but I can make some remarks from the engineering POV :-). Presumably you're talking about TzSpecificLocalTimeToSystemTime, we clearly missed that one, although it's interesting that all the other functions are supported from W2K on. Regardless, even if we did notice we would likely just recommend bumping up the support constraints to W2K3. W2Ks final (extended) EOL deadline seems to be coming up in 2 months, that clearly doesn't justify extra effort to accommodate it.

Possible work-around is switching back to the plain Smalltalk TimeZone, as the (still the same old) TimeZone settings page shows. Obviously you won't get any of the SystemTimeZone advantages that way, more details on that can be found in the release notes.

HTH,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Steven Kelly"<[hidden email]> wrote:
While I can understand that your workaround may be fine for your application specifically, it doesn't seem to me like something we could adopt for the product in general (as it gives you up to 12 hours of error depending on your TZ). You could try to set up a compromise using the CompositeTimeZone, e.g:

        CompositeEasternForWindows := "There was no DST before 1600"
                (CompositeTimeZone default: (TimeZone timeDifference: -5 DST: 0 at: 0 from: 0 to: 0 startDay: #Sunday))
                        startingInYear: 1601 use: SystemTimeZone new;
                        yourself.
        TimeZone setDefaultTimeZone: CompositeEasternForWindows

But again we can't easily do that for VW in general. We'd need the ability to detect the OS TZ (which is doable) but we'd also have to have Smalltalk equivalents for all timezones, at which point you may as well just load Chronos. On the other hand this sort of workaround is much more feasible for specific deployments.

Cheers,

Martin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 06.05.2010 15:53, schrieb [hidden email]:
I'm wondering under which circumstances there will ever be a difference
between Timezone null and Timezone default when using #asSeconds or
#fromSeconds:. #asSeconds and #fromSeconds do not involve any
timezone-related api (#universalToLocal:, #localToUniversal:) when using
the system timezone.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> > "Timestamp zero asSeconds" blows up on Windows...
> > For now, we've overridden #asSeconds to handle errors with [:ex | ex
> > return: (TimeZone null timestampToSeconds: self)]. That seems to
work
> > well as a stopgap
>
> While I can understand that your workaround may be fine for your
> application specifically, it doesn't seem to me like something we
could
> adopt for the product in general (as it gives you up to 12 hours of
> error depending on your TZ).

Sure. The places we had Timestamp zero were all using Timestamps as a
way of doing arithmetic and comparisons (in the olden days Date and Time
weren't as good at this as Timestamp). In those places, the null
timezone makes sense as a fallback (and indeed is better than any real
timezone, since it doesn't mess around with DST).

What base VW should do is a tricky question. Essentially this is an "out
of supported range" situation, so not an error like dividing by zero.
The answer to the question exists (albeit with possible slight
inaccuracies for distant years), the OS just can't be bothered to work
it out. I think at the least the error should be raised as a
platform-independent error specific to this problem. Currently it is
raised as a generic Error, although the code that does it is the same
across platforms. Also, the documentation should list the range
supported by each platform, and the safe range for all platforms.

Ideally the calculation should just extend infinitely in both
directions, using Smalltalk to apply the current OS timezone rules to
times outside the range supported by the OS. That was what happened with
the earlier OSTimeZone package, and of course with VW before that
(although you had to enter the TimeZone data manually).

Currently, it looks like we've lost any dates outside 1901-2038 on Unix,
which is a pretty big loss. I'd much rather be able to get a half-decent
answer to "how many days since the pyramids were built in 2750BC" or
"milliseconds until the next appearance of Halley's comet", than an
error message because the OS wasn't sure of the leapsecond rule that far
out. Smalltalk seamlessly extends the range for numbers, but 7.7 has
seriously limited the range for Timestamps.

Cheers,
Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Steven Kelly"<[hidden email]> wrote:
> What base VW should do is a tricky question. Essentially this is an "out
> of supported range" situation, so not an error like dividing by zero.
> The answer to the question exists (albeit with possible slight
> inaccuracies for distant years), the OS just can't be bothered to work
> it out. I think at the least the error should be raised as a
> platform-independent error specific to this problem. Currently it is
> raised as a generic Error, although the code that does it is the same
> across platforms.

We could certainly do that, although it seemed to us that this kind of failure is something that developers would have to sort out during development (e.g. by setting up a composite timezone etc) and not by trying to deal with it at runtime in a deployed application, in which case specific error class didn't seem worth it.

> Also, the documentation should list the range
> supported by each platform, and the safe range for all platforms.

We did try to list all the known limitations in the release note, was that insufficient ? I'm not sure if the doc updates in 7.7.1 will include platform specific details, I suspect our doc guys generally try to avoid those in the docs.

> Ideally the calculation should just extend infinitely in both
> directions, using Smalltalk to apply the current OS timezone rules to
> times outside the range supported by the OS. That was what happened with
> the earlier OSTimeZone package, and of course with VW before that
> (although you had to enter the TimeZone data manually).

As far as I can see even the latest version of OSTimeZone is able to get the necessary TZ parameters from the OS only for Win32 platforms. And that's only to power the limited model of the classic TimeZone definition. My point was that to do a decent job you just can't get by without the full TZ database (either hidden behind some OS calls, or directly available at the smalltalk level, which is exactly what Chronos does). On the other hand not every customer would find the cost of Chronos in the base image acceptable, if they don't need it. That's why it's great to have it as a loadable option for those who do.

>From 300 foot POV, it's quite likely that a large percentage of applications should be fine within the constraints of the OS timezone capabilities. Otherwise the OSes wouldn't get away with being so constrained in the first place. On top of it SystemTimeZone elegantly addresses our long standing and loud complaint of VW not synchronizing its TZ settings with the OS. It clearly won't fit everyone's needs, and hopefully we can address those with various workarounds.

> Currently, it looks like we've lost any dates outside 1901-2038 on Unix,
> which is a pretty big loss. I'd much rather be able to get a half-decent
> answer to "how many days since the pyramids were built in 2750BC" or
> "milliseconds until the next appearance of Halley's comet", than an
> error message because the OS wasn't sure of the leapsecond rule that far
> out. Smalltalk seamlessly extends the range for numbers, but 7.7 has
> seriously limited the range for Timestamps.

I can't quite agree with that statement. You can still create and work with Timestamps for arbitrary points in time, you just may run into limits *in the default configuration* with operations that require a timezone. As you already pointed out we hope Durations will help in that department. And if the default configuration just doesn't work well enough for you, you still have the option of going back to the old timezone setup (which always required manual setup so that's no different from switching back to it now), or load Chronos or whatever. But I'm quite confident that none of those options is such that it will fit everyone's requirements perfectly.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Holger Kleinsorgen"<[hidden email]> wrote:
> I'm wondering under which circumstances there will ever be a difference
> between Timezone null and Timezone default when using #asSeconds or
> #fromSeconds:. #asSeconds and #fromSeconds do not involve any
> timezone-related api (#universalToLocal:, #localToUniversal:) when using
> the system timezone.

Not sure what you mean, conversion between timestamps and second counts most definitely should and does involve the timezone, otherwise you can't account for DST or leap seconds or years.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

The release notes are first rate! Many thanks for them, and sorry that
I'd forgotten the details. I knew that our app did nothing even vaguely
interesting with time and dates, so was surprised when things broke down
in quite a few places. Code like "Time now asTimestamp asSeconds" and
"Timestamp zero asSeconds" wasn't something I thought would break, so I
thought I'd mention it in case others had code like that.

Maybe we could have something a bit like CompositeTimeZone as the
default. If the Timestamp was less than the first year or greater than
the last year supported by the OS, it would simply change the year to be
in range, calculate the result for that year with the OS, and then add a
generic amount for the number of years to the original argument.

Having said that, my #asSeconds hack seems to do surprisingly well. I
just tried this:

future := Date newDay: 180 year: SmallInteger maxVal.
history := Date newDay: 180 year: SmallInteger maxVal negated.
future - history

and got the correct answer (~365.25 * SmallInteger maxVal * 2). Without
#asSeconds falling back to TimeZone null, that calculation gives two
errors. I think users might be surprised that date calculations would
fail just because of the OS timezone range. Date certainly doesn't
mention it in its comment, which promises any Julian date. (One problem
with PDF release notes and manuals for permanent documentation is that
we're Smalltalkers :-). We read source code and class comments more than
PDFs (or at least I do). But that's a different conversation.)

Steve
zero.
> > The answer to the question exists (albeit with possible slight
> > inaccuracies for distant years), the OS just can't be bothered to
> work
> > it out. I think at the least the error should be raised as a
> > platform-independent error specific to this problem. Currently it is
> > raised as a generic Error, although the code that does it is the
same try
> to avoid those in the docs.
>
> > Ideally the calculation should just extend infinitely in both
> > directions, using Smalltalk to apply the current OS timezone rules
to cost
> of Chronos in the base image acceptable, if they don't need it. That's
> why it's great to have it as a loadable option for those who do.
>
> From 300 foot POV, it's quite likely that a large percentage of
> applications should be fine within the constraints of the OS timezone
> capabilities. Otherwise the OSes wouldn't get away with being so
> constrained in the first place. On top of it SystemTimeZone elegantly
> addresses our long standing and loud complaint of VW not synchronizing
> its TZ settings with the OS. It clearly won't fit everyone's needs,
and old
> timezone setup (which always required manual setup so that's no
> different from switching back to it now), or load Chronos or whatever.
> But I'm quite confident that none of those options is such that it
will
> fit everyone's requirements perfectly.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 06.05.2010 17:35, schrieb [hidden email]:
> "Holger Kleinsorgen"<[hidden email]>  wrote:
>> I'm wondering under which circumstances there will ever be a difference
>> between Timezone null and Timezone default when using #asSeconds or
>> #fromSeconds:. #asSeconds and #fromSeconds do not involve any
>> timezone-related api (#universalToLocal:, #localToUniversal:) when using
>> the system timezone.
>
> Not sure what you mean, conversion between timestamps and second counts most definitely should and does involve the timezone, otherwise you can't account for DST or leap seconds or years.
>

1601 to: 30827 do: [: year |
   1 to: 12 do: [ : month |
     | timestamp nullSeconds systemSeconds nullTimestamp systemTimestamp  |
     timestamp := (Date newDay: 1 monthNumber: month year: year)
asTimestamp.
     nullSeconds := TimeZone null timestampToSeconds: timestamp.
     systemSeconds := TimeZone default timestampToSeconds: timestamp.
     nullSeconds = systemSeconds ifFalse: [ self halt ].
     nullTimestamp := TimeZone null secondsToTimestamp: nullSeconds.
     systemTimestamp := TimeZone null secondsToTimestamp: nullSeconds.
     nullTimestamp = systemTimestamp ifFalse: [ self halt ].
   ].
].


The code above never halts.

On Windows, "timestamp asSeconds" boils down to a call to
SystemTimeToFileTime(). MSDN says:

"Converts a system time to file time format. System time is based on
Coordinated Universal Time (UTC).". FILETIME is based on UTC, too.

So no timezone-related adjustements are made (DST etc.). It only
converts a UTC FILETIME to a UTC SYSTEMTIME.

Timezone-related adjustements are only done when sending
#localToUniversal: / #localToUniversal: (like "Timestamp now" does).
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

"Steven Kelly"<[hidden email]> wrote:
Yes, as Holger pointed out I was wrong about the TimeZone null fallback, it seems that it is feasible to extrapolate the functional range of #asSeconds/#fromSeconds: beyond the SystemTimeZone range, at least as the default configuration (some applications still may not be OK with the extrapolation, so there should be a way to get the conversions to fail if desired). Note however that it still won't get you too far in terms of working with Timestamps.

Arguably, the 'future - history' expression should assume that the future and history are in local timezone (that's what you get from Timestamp now and Date today, and that's what most applications would expect, given that Timestamps (as they are today) don't have explicit indication of their timezone). Therefore the implementation of Timestamp>>- should really first convert the timestamps to UTC and only then apply the asMilliseconds calls which treat the receivers as UTC timestamps.

So even if we do fix things up for asSeconds/fromSeconds:, you're still really tied to purely UTC computations, which won't help much in most cases. At that point is it even worth it ?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc