Archive for April, 2009

Python like .NET

Friday, April 17th, 2009

Python allows you to assign almost everything.  There doesn’t seem to be a difference between variables and functions.  You can have a class Foo with attributes bar and baz. These can be methods or plain varaibles, and you can re assign them at run time.   So Foo.bar = 10  and Foo.bar = { return a+1 }  are both valid (though not valid python syntax).   This allows you to reassign methods/functions at run time.

.NET has a simular feature called Delegates.  These are basicly pointers to function.  Most people will use these for callbacks and events.  Something interesting you can do is use them in properties.

class Foo
{
  delegate void Fn(string s);
  Fn bar;
  Fn baz
  public Fn Bar{
    get{ return bar; }
    set{ bar = value; }
  }
  public Fn Baz{
    get{ return baz; }
    set{ baz = value; }
  }
}

Using this class you can now assign the class methods at runtime.

Calling the method:

f.Baz("something")

and reassign the function to print out a line

f.Baz = f => Console.WriteLine(f);

The class looks just like it has normal methods, but they are not assignable.

Fun with timezones

Thursday, April 9th, 2009

Using dates and times in a program is not always as straight forward as you might think.  The issue is with timezones and daylight savings.  Most people forget to use a timezone when they store dates.  This might not seem like an issue if you think your program will never be used in another timezone, but it still is.

Timezones tell you how to convert your datetime from one timezone to the other.  10am in NYC is not the same 10am in Tokyo.  What makes this all the more fun is the wonder idea of daylight savings time.  Time will go backwards and forwards or seeming random days.  Suddenly there are 2 different 11:59pm.

When you look at a file in windows explort, did you ever think about the missing timezone on the dates?  You probably didn’t give it a second thought.  But you should.  You probably assume that it is showing the times in your current time zone.   Sadly you are more correct then you think.  I found out about this after I read this link.  It seems windows uses your CURRENT timezone to display the datetime.  Whats the problem with this?  If a file was created at 3/1 10:00pm and you look at the file in April, windows shows the file date as 11:00pm, even though the correct time should be 10:00pm.

Windows is smart enough to store the date in UTC/GMT/ZULU time, but when converting it back to your local timezone, it just uses your CURRENT timezone offset, instead of figuring out what it was on that date with DST factored in.  I wonder if someone was trying to optimize out a few CPU cycles.

So next time you are looking at the access times on your files, remember that they could be up to an hour off from what the actual time was.