We're using the default .Net AssemblyVersion attribute value of 1.0.*
For some reason, when we use the version number to calculate the time the
assembly was built, it's coming out an hour ahead of the actual time.
The algorithm that is used to generate the version number is supposedly:
"When specifying a version, you have to at least specify major. If you
specify major and minor, you can specify an asterisk (*) for build. This
will cause build to be equal to the number of days since January 1, 2000
local time, and for revision to be equal to the number of seconds since
midnight local time, divided by 2."
(From
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlr
fSystemReflectionAssemblyVersionAttributeClassctorTopic.asp)
However, using this algorithm to desk check the assembly version on my own
machine, it comes up an hour ahead.
Anyone got any clues to the cause of this? It's easy enough to subtract an
hour, but I'd like to know why it's not working as intended.
Niall
Christoph Nahr - 24 May 2004 07:36 GMT
>We're using the default .Net AssemblyVersion attribute value of 1.0.*
>
>For some reason, when we use the version number to calculate the time the
>assembly was built, it's coming out an hour ahead of the actual time.
Summer time adjustment perhaps?

Signature
http://www.kynosarges.de
Niall - 25 May 2004 00:30 GMT
I tried building the assembly then checking the version straight after on
the same machine, so the clocks were the same, as were the time zones. We're
outside of daylight saving time in Australia currently
Niall
> >We're using the default .Net AssemblyVersion attribute value of 1.0.*
> >
> >For some reason, when we use the version number to calculate the time the
> >assembly was built, it's coming out an hour ahead of the actual time.
>
> Summer time adjustment perhaps?