DateTime fundamentally broken

[piersh]

Does anyone know how to make the following method work across
timezones?

[WebMethod]
public DateTime GetTime ()
{
return DateTime.UtcNow;
}

[William Stacey [MVP]]

Is it not returning the UTC time at the client?

--
William Stacey, MVP
http://mvp.support.microsoft.com

<pi****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

Does anyone know how to make the following method work across
timezones?

[WebMethod]
public DateTime GetTime ()
{
return DateTime.UtcNow;
}

[piersh]

not if the client & server are in different time zones.

client code:
Console.WriteLine (service.GetTime ().ToString ("s"));

[piersh]

not if the client & server are in different time zones.

client code:
Console.WriteLine (service.GetTime ().ToString ("s"));

[Stephany Young]

No, it is returning the current date/time OF the server, converted to UTC,
TO the client.

What the server is saying is that at the time that I executed the
DateTime.UtcNow method, the date/time was <whatever> in terms of UTC.

The whole crux of your original questions depends entirely upon what your
definition of 'work across timezones' is.
"William Stacey [MVP]" <st***********@mvps.org> wrote in message
news:O3**************@TK2MSFTNGP10.phx.gbl...

Is it not returning the UTC time at the client?

--
William Stacey, MVP
http://mvp.support.microsoft.com

<pi****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

Does anyone know how to make the following method work across
timezones?

[WebMethod]
public DateTime GetTime ()
{
return DateTime.UtcNow;
}

[William Stacey [MVP]]

Does the following give you the correct time?

Console.WriteLine(service.GetTime().ToLocalTime(). ToString("s"));

--
William Stacey, MVP
http://mvp.support.microsoft.com

<pi****@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

not if the client & server are in different time zones.

client code:
Console.WriteLine (service.GetTime ().ToString ("s"));

[William Stacey [MVP]]

The other thing is the way the serializer handles DateTimes. Even if the
date is UTC, it will put the TZ on the wire like:
<dateTime>2005-04-06T05:12:10.5468750-04:00</dateTime> (note Eastern TZ).

This is not correct as it should be Zulu time with no timezone. Not sure
how that will be handled in all cases at different timezones. Therefore,
when I pass DateTime, I always work in Zulu time and pass the date myself as
a string. That way I always know it is a true UTC and I can convert to
local time if needed at the client side. Use these two methods for the
conversions. ToUTCDateTimeString at the server and FromUTCDateTimeString at
the client.

/// <summary>
/// Returns string formatted in Zulu (UTC) time. value must be UTC
DateTime.
/// </summary>
/// <param name="value"></param>
/// <returns></returns>
public static string ToUTCDateTimeString(DateTime value)
{
// Date expected to be UTC date already.
// e.g 2003-10-26T14:33:41.1234567Z
return value.ToString("yyyy-MM-ddTHH:mm:ssZ",
CultureInfo.InvariantCulture);
}

/// <summary>
/// Parses the UTC formatted string, returning DateTime in UTC.
/// Use ToLocalTime() on the result if you want to convert to local time.
/// </summary>
/// <param name="value"></param>
/// <returns></returns>
public static DateTime FromUTCDateTimeString(string value)
{
return DateTime.Parse(value, CultureInfo.InvariantCulture,
DateTimeStyles.AdjustToUniversal);
}

--
William Stacey, MVP
http://mvp.support.microsoft.com

<pi****@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

not if the client & server are in different time zones.

client code:
Console.WriteLine (service.GetTime ().ToString ("s"));

[piersh]

> Therefore, when I pass DateTime, I always work in Zulu time and pass
the date myself as a string.

This is exactly what I'm doing now (except I'm using date.ToString
("s"); )

This implies that the current Microsoft Serializer behaviour is either:

1) completely useless
2) a bug
3) all of the above

I'd love to hear from an MSFT guy what the rational behind this was.

[piersh]

> The whole crux of your original questions depends entirely upon what
your definition of 'work across timezones' is.

I want the client to receive a DateTime that holds the UTC time on the
server.

However, since Microsoft chose to transfer the dates using a
time-zone-sensitive format (the dates are treated as relative to the
local timezone on each machine) this only works if both the client &
the server are in the same timezone. Otherwise, the DateTime receives
is shifted by the time difference between the two timezones.

[William Stacey [MVP]]

You need to do the zulu "Z" thing as I shown to get the transfer right.
Once you have the DateTime after using FromUTC method (and using ToLocal if
you wish), then you can format as needed with "s" or what ever you want for
output. I would keep all dates in UTC as long as possible and only go to
local time when you want to display. All date calcs should be in UTC.

1) completely useless
2) a bug
3) all of the above

I'd love to hear from an MSFT guy what the rational behind this was.

Some poor early design decisions. Brad Abrams from MS talks frankly about
most of the issues here:
http://blogs.msdn.com/brada/search.aspx?q=datetime&p=1

--
William Stacey, MVP
http://mvp.support.microsoft.com