DST set on server? - Page 2

*falconeye* · 03-27-2008, 04:18 AM

Originally Posted by PDL

Truth be told, all Windows systems based on the NT Kernel architecture use GMT as their time. The time zone is a filter so us poor humans can make sense of it. I would imagine that he server farm in TX is getting its base time from either a feed from the NIST time standard or a GPS system.

Ok, back to serious here...

Windows isn't involved here. The time as far as windows sees it is just 5 letters of text coming from the server.

The vB web pages could have used Javascript to ask the browser do the time conversion locally but they don't.

The server doesn't care about the server farm it is part of. I assume it is a plain old Apache/Linux. Those get their time over the internet using the NTP protocol from servers like ntp2.sandvika.net or ntp1.tpg.com.au or ntp2d.mcc.ac.uk etc.

This is like using an exact clock service as Physikalisch-Technische Bundesanstalt (PTB) (Java, the official German atomic clock

)

However, the NTP protocol always uses UTC (universal time).

The vB software will now use a user's timezone (GMT +/-X) from its profile and guess DST from the data. This guessing may be done based on the timezone or be done globally. In either case, the dates when the US goes to DST may not have been updated or cannot be used. The latter is the case if the majority of a timezone has different DST rules (e.g., Central Time does also apply to Mexico City).

One would need several entries for a given GMT timezone which vB doesn't support.

After all this has been done, times are individually converted to text for the user requesting a web page.

PDL · 03-27-2008, 07:37 AM

Originally Posted by falconeye

Ok, back to serious here...

Windows isn't involved here. The time as far as windows sees it is just 5 letters of text coming from the server.

The vB web pages could have used Javascript to ask the browser do the time conversion locally but they don't.

The server doesn't care about the server farm it is part of. I assume it is a plain old Apache/Linux. Those get their time over the internet using the NTP protocol from servers like ntp2.sandvika.net or ntp1.tpg.com.au or ntp2d.mcc.ac.uk etc.

This is like using an exact clock service as Physikalisch-Technische Bundesanstalt (PTB) (Java, the official German atomic clock )

However, the NTP protocol always uses UTC (universal time).

The vB software will now use a user's timezone (GMT +/-X) from its profile and guess DST from the data. This guessing may be done based on the timezone or be done globally. In either case, the dates when the US goes to DST may not have been updated or cannot be used. The latter is the case if the majority of a timezone has different DST rules (e.g., Central Time does also apply to Mexico City).

One would need several entries for a given GMT timezone which vB doesn't support.

After all this has been done, times are individually converted to text for the user requesting a web page.

I assume that the Server Farm in TX is using an IP in the US. Here make a selection -
NIST Internet Time Service No - users in the US do not have to use German clocks.

Also the DST for Mexico and the US are NOT the same as Mexico did not adopt W's new DST dates. They did not drink the cool-aid e.g.
Mexico City Thu 7:14 AM
Houston Thu 8:14 AM
GMT Thu 13:14:31

My point was back to canadian_rockies about using GMT. Under the hood on Windows systems the file system time stamps in GMT - the user sees the filtered local time according to what time zone the user is is. If canadian_rockies is using Windows and wants to change his time to GMT - then just change the filter. Since he is in Canada - I bet he is not using a US time source either.

I hope you are not implying that the vB application is checking time independently from the OS - what ever it is. Any application that manages time independently of the OS is just asking for trouble and is a good example of Pcubed (PPP -> P*ss Poor Programing). It is possible that the server farm that where this site is running (could be a virtual machine) has not patched for the new US DST time period. I would hope that they have patched the systems - since the patches came out over a year ago (MS issued patches in January 2007). I hope a Linux system would have been patched by now.

The Elitist - formerly known as PDL

*falconeye* · 03-27-2008, 08:25 AM

Originally Posted by PDL

I assume that the Server Farm in TX is using an IP in the US. Here make a selection -
NIST Internet Time Service No - users in the US do not have to use German clocks.

Oh dear. Was I that unclear?

Of course, the German clock was just a cute example to explain what an internet time service actually does (and Google, as wise as it is, preferred to pop up a German service for me top of the list...).

BTW, internet servers neither use NIST (US) nor PIB (Germany), anyway.

They use a standardized internet protocol called NTP (network time protocol) (a bit like HTTP for web pages).

Therefore, it doesn't matter much which NTP server is asked, they all reply in UTC (universal time) anyway. I agree, it will likely be a US server.

BTW, the servers in the server farm will not have to share the same NTP server.

Originally Posted by PDL

I hope you are not implying that the vB application is checking time independently from the OS - what ever it is. Any application that manages time independently of the OS is just asking for trouble

I am implying nothing. No internet server can use the local timezone or local DST policy. As they are accessed by users all over the world. They do use the current universal time of the OS which must be UTC (which is the standard with Unix or Vista anyway).

So, it is up to the web application (vB) to figure out what time zone and DST is in effect for a particular user. But only knowing the offset in hours, it cannot distinguish between Mexico and the US.

CycloneBandDad · 03-27-2008, 12:06 PM

Originally Posted by falconeye

You are making jokes with me.

I looked up where the server is physically located at, it is "Dallas Datacenter", TX, USA.

The vB software however is programmed in the UK and those guys will be glad to ignore Mr. Bush's decisions, I am sure

Speaking as a programmer who had to deal with the fallout of that choice, let us just clarify that it was CONGRESS that changed that, not the President.

And, if I only we could get rid of DST in our database applications and make everyone work in UTC across the board (we store times in UTC, and convert them to & from Local times on input or output - what a silly concept but we are stuck with it...)

Jim

CycloneBandDad · 03-27-2008, 12:23 PM

Originally Posted by mtnbearhug

Well Hell Falconeye... no wonder the time is confused... one part says one time.. (usa) and the other part says another (UK)... my heads gettin dizzy with all of these.. lol

Oh, it gets worse, Kim... Parts of the USA observe DST, but some states opt out and do not change (Arizona for example). And in Indiana, the state itself has parts observing DST and parts that dont... If you think it is hard to keep track of in your head, pity the folks who have to program all the changes into a computer system. Especially when they have to deal with a database that holds millions of time-tagged measurements that can date back not only before the recent changes to DST dates, but before DST itself. And sites that can be located worldwide, so *every* time zone must be handled. And where every site can be tagged to operate in a given time zone, regardless of the time zone it's physically located in, AND it can be tagged to either observe or ignore DST whatever the state it is located in does... You thought *your* head got dizzy?!?!? Youch!

Jim

*Canada_Rockies* · 03-27-2008, 02:59 PM

Originally Posted by CycloneBandDad

Oh, it gets worse, Kim... Parts of the USA observe DST, but some states opt out and do not change (Arizona for example). And in Indiana, the state itself has parts observing DST and parts that dont... If you think it is hard to keep track of in your head, pity the folks who have to program all the changes into a computer system. Especially when they have to deal with a database that holds millions of time-tagged measurements that can date back not only before the recent changes to DST dates, but before DST itself. And sites that can be located worldwide, so *every* time zone must be handled. And where every site can be tagged to operate in a given time zone, regardless of the time zone it's physically located in, AND it can be tagged to either observe or ignore DST whatever the state it is located in does... You thought *your* head got dizzy?!?!? Youch!

Jim

And at the Western edge of Mountain Time Zone, the communities of Yahk and Creston decided that they will not change their clocks. They move the time zone to the other side twice a year. In winter, they are on Mountan Standard Time, in the summer, Pacific Daylight Time. Thus, you never know without a calculator when to leave for the annual bridge tournament.

*falconeye* · 03-27-2008, 07:11 PM

Originally Posted by CycloneBandDad

it can be tagged to either observe or ignore DST whatever the state it is located in does... You thought *your* head got dizzy?!?!? Youch!

You're triggering my programmer's heart

Yeah, this is why good programmers earn good money, right

BTW, as we have been told, algorithm beats implementation. So, here is an easy fix to the vB developers to solve all of the problems mentioned above (and even with the bridge below

).

Add an (approximate) GPS field to the user profile and use a webservice like

http://ws.geonames.org/timezone?lat=...g=130.98789400

to resolve it the exact timezone and DST setting. Just adds ten lines of code (a bit more with proper caching)