MLton's implementation of Date.localOffset is derived from the implementation in the MLKit. I suspect that part of the confusion is the fact that the it isn't clear that the interpretation of the offset field in the record passed to the Date.date function is really a whole other story --- they would seem to be related somehow. And the confusing thing about the description of the offset is that it states "Negative offsets denote time zones to the east of UTC, as is traditional. Offsets are taken modulo 24 hours." But, Int.mod of a negative by a positive is necessarily a positive, so it isn't clear that one would ever see a negative offset. (Note that Int.mod(~10, 24) = 14.) It seems that the intention is that an offset is between -24 and +24; or should it be between -12 and 12. It seems that the Date module documentation could use some more examples to clarify the behavior.

On Tue, Jun 8, 2010 at 10:21 PM, Michael Norrish Michael.Norrish@nicta.com.au wrote:

My machine is Linux michaeln-desktop 2.6.31-22-generic #60-Ubuntu SMP Thu May 27 00:22:23 UTC 2010 i686 GNU/Linux

Consider:

?print (Time.toString (Date.localOffset()) ^ "\n")

poly (5.3) gives:

?~36000.000 ? (-10 hours)

Moscow ML (2.01) gives:

?50400.000 ? ?(+14 hours)

mlton (20070826) gives:

?50400.000

sml/nj (v110.69) gives

?~36000.000

Local time (Australian east coast in cold, cold winter) is 10 hours ahead of UTC.

The Basis says:

?The offset from UTC for the local time zone.

(Moscow ML's behaviour is consistent with its own documentation, but it doesn't pretend to implement Basis 2002.)

It seems to me that the answer should actually be +10 hours, because that is what you add to UTC to get *from* UTC to my local time.

Note that the Basis documentation for interpreting the offset field in the record passed to the Date.date function is a whole other story.

(I don't know who/what to write to for SML/NJ.)

Michael.

---

MLton mailing list MLton@mlton.org http://mlton.org/mailman/listinfo/mlton