Fixed SL5 build, but also other builds (please see comment below). Should be painless to integrate this. Also, please let me know next time you want to push a new NuGet build so that I can update SL5 binaries, thanks!

[ddotlic]

Microsoft recommends to use TimeZoneInfo instead of TimeZone for all recent
versions (starting from 3.5) of the .NET, plus this is the only class
available in non-mainstream flavors of .NET (like Silverlight),
so why not use it.
Also update the assembly version of the SL5 build of ServiceStack.Text.

[ddotlic]

@mythz You must be absolutely the fastest pull request integrator ever 😄 Cheers!

[mythz]

@ddotlic I try my best :) FYI I've just pre-INCR the version numbers of the SS.Text and SS projs so they have the future version numbers for the next release of ServiceStack: 188924a

This should let you add new builds at anytime before the next release (happens every 2 weeks, ending Sunday) and they should retain the same version number.

I'll try remember to pre-INCR the version numbers for future releases.

[ddotlic]

@mythz Actually, you were already pre-incrementing the version for a while I think, the question here is simply when should I update the binaries so that they end up in the NuGet package. The schedule might be every two weeks, but it isn't always due to the sometimes necessary hot fixes I guess. If you could remember just to give me heads up next time, I'll be happy to update SL5 builds just prior to NuGet push. Thanks again and regards.

[mythz]

I recommend aiming to add them anytime on the weekend as I prefer not to add any dependency blockers (i.e. waiting on communication) to the release process.

The Silverlight builds were nearly a year behind before you started updating them, if you upload them on the weekend they should only be at most a couple of commits behind.

[ddotlic]

@mythz Yeah, OK, when you put it that way, then it indeed makes sense to just update them from time to time (on the the weekend), much better than to wait for a year or so 😃 Got it, thanks.