最严重的字节表示YYYYMMDDHHMMSS？ [英] Tightest Byte Representation of YYYYMMDDHHMMSS?

问题描述

我需要使用UTC datetime包装字符串，使用最小的字节/字符数。我只需要精确到秒。使用.NET 4.0，什么是最节省空间的方式来打包呢？ Ticks似乎并不那么小。

I need to pack string with a UTC datetime, using the smallest number of bytes/characters. I only need precision to the second. Using .NET 4.0, what would be the most space-efficient way to pack this down? Ticks doesn't seem all that small.

所有想法赞赏。
谢谢。

All ideas appreciated. Thanks.

编辑：感谢Joel Coehoorn，打包/解压缩动作是最好的。谢谢！下面是一些证明：

Thanks to Joel Coehoorn, the pack/unpack move is the best. Thanks! Here is some proof:

DateTimeOffset nowStamp = DateTimeOffset.UtcNow;
        Console.WriteLine( nowStamp.ToString() );                   // 9/9/2011 2:17:17 PM +00:00
        Console.WriteLine( nowStamp.ToString( "u" ) );              // 2011-09-09 14:17:17Z
        Console.WriteLine( nowStamp.Ticks.ToString() );             // 634511746376767889
        Console.WriteLine( PackDate( nowStamp ) );                  // 7R9qTgAAAAA=
        Console.WriteLine( UnpackDate( PackDate( nowStamp ) ) );    // 9/9/2011 2:17:17 PM +00:00

推荐答案

也许unix时间的变体（从1970年1月1日以来的秒数，而不是毫秒）base64编码。

Perhaps a variant on unix time (seconds since 1/1/1970 rather than milliseconds) base64 encoded.

//Helpers
private static DateTime Jan1st1970 = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);
public static long toUnixTime(this DateTime d)
{
    return (long)((d.ToUniversalTime() - Jan1st1970).TotalMilliseconds);
}

public static string Base64Encode(long toEncode)
{
    return Convert.ToBase64String(BitConverter.GetBytes(toEncode));
}

//Encode
public static string PackDate(DateTime toPack)
{
    return Base64Encode(toPack.toUnixTime()/1000);
}

//Decode
public static DateTime UnpackDate(string toUnpack)
{
    long time = BitConverter.ToInt64(Convert.FromBase64String(toUnpack),0);
    return Jan1st1970.AddSeconds(time); //you may or may not want a "ToLocaltime()" call here.
}

请注意，这一切都是在没有IDE的帮助下完成的 - bug或两个以上。但它应该让你开始。

Note that all this was done without the aid of an IDE - there's likely a bug or two above. But it should get you started.

这将导致一个固定宽度的字符串。因为我们只是做秒而不是毫秒，你可能会发现你总是有一些额外的填充结果，你不需要。你甚至可以得到一个int，而不是一个长，这将把字符串减半。要小心剥离填充，虽然，越接近你到1970年，数字越小，但越远，你得到的越大，你越有可能需要它。您需要确定，您的日期值将适合新的，更小的范围内做任何修剪。例如，当前日期适合在一个int内，但即使28年后，也不会。 UInt32会让你稍后更进一步，但阻止你在1970年之前使用日期。

This should result in a fixed-width string. Since we're only doing seconds rather than milliseconds, you may find you always have some extra padding in the result that you don't need. You might even be able to get away with an int, rather than a long, which will cut the string in half. Be careful stripping that padding out, though, as the closer you get to 1970 the smaller the number, but the farther you get the larger and the more likely you are to need it. You need to be certain that your date value will fit within the new, smaller range for doing any trimming. For example, the current date fits comfortably within an int, but even 28 years from now will not. UInt32 will get you a little further into the future, but prevent you from using dates before 1970.

这篇关于最严重的字节表示YYYYMMDDHHMMSS？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！