views:

31

answers:

0

Something doesn't seem right about the source code for Flash Remoting's Date(AS3) <-> DateTime(.NET) stream reader/writer methods, when it comes to handling UTC <-> Local times.

It seems to write the DateTime data fine, including a 64-bit representation as milliseconds elapsed since Jan 1, 1970, as well as a UTC offset.

public void WriteDateTime(DateTime d)
{
    this.BaseStream.WriteByte(11);
    DateTime time = new DateTime(0x7b2, 1, 1);
    long totalMilliseconds = (long)d.Subtract(time).TotalMilliseconds;
    long l = BitConverter.DoubleToInt64Bits((double)totalMilliseconds);
    this.WriteLong(l);
    int hours = TimeZone.CurrentTimeZone.GetUtcOffset(DateTime.Today).Hours;
    this.WriteShort(hours);
}

But when the data is read... it seems to be ignoring the short UTC offset value that was written, and appears to just discard it!

private DateTime ReadDateValue()
{
    long num2 = (long)this.ReadDouble();
    DateTime time2 = new DateTime(0x7b2, 1, 1).AddMilliseconds((double)num2);
    int num3 = this.ReadInt16() / 60; //num3 is not used for anything!
    return time2;
}

Can anyone make sense of this?

I also found some similar source code for AMFReader here, which has a ReadDateTime method, that seems to do something very similar... but goes on to use the UTC offset for something.