1
votes

We have timestamps from CSV files that look like this:

06-02-2018 15:04:21

We do not control the delivery of them, nor the timezone.

What we do know so far is that we have seen so far is this:

Standard Romance Time Standard Romance Time, but without DST compensation. UTC

From this, we gather that we need an engine that can take any timestamp (written in patterns that DateTime.ParseExact understands), belong to any timezone, optionally ignore DST, and then convert it to UTC (the format we internally use).

I was hoping this could do it:

public DateTime ConvertToUtc(string fromTimestamp, DataReaderConfiguration dataReaderConfiguration)
{
  DateTime readTime = DateTime.ParseExact(fromTimestamp, dataReaderConfiguration.TimestampFormat,
    CultureInfo.InvariantCulture, DateTimeStyles.None);
  DateTime utcTime = TimeZoneInfo.ConvertTimeToUtc(readTime,
    TimeZoneInfo.FindSystemTimeZoneById(dataReaderConfiguration.TimeZone));
  return utcTime;
}

but C# does not have timezones defined without DST (except for UTC).

So we need to expand on the method to allow for a timezone conversion without DST.

1

1 Answers

1
votes

You can create this function yourself, by leveraging the TimeZoneInfo.BaseUtcOffset property and a DateTimeOffset.

public static DateTime ConvertTimeToUtc(DateTime dt, TimeZoneInfo tz, bool useDST)
{
    if (useDST)
    {
        // the normal way (converts using the time in effect - standard or daylight)
        return TimeZoneInfo.ConvertTimeToUtc(dt, tz);
    }

    // the way to convert with just the standard time (even when DST is in effect)
    var dto = new DateTimeOffset(dt, tz.BaseUtcOffset);
    return dto.UtcDateTime;
}

Then just pass whatever property from your DataReaderConfiguration object that indicates whether you want to use DST (or negate it if necessary).

Also note that this gives the standard time based on the current set of rules. If you are dealing with historical dates where the time zone's standard time has changed, things get a bit more complex. You'd have to figure out which adjustment rules were in place at the time, etc. You might even find edge cases where the Windows time zone data is insufficient.