Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14423 > unrolled thread

Dealing with timestamps from different timezones - general approach for basic saving?

Back to article view | Back to comp.lang.php

Contents

  Dealing with timestamps from different timezones - general approach for basic saving? e.blumstengel@googlemail.com - 2014-10-28 12:42 -0700
    Re: Dealing with timestamps from different timezones - general approach for basic saving? Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-28 16:51 -0400
      Re: Dealing with timestamps from different timezones - general approach for basic saving? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-30 08:14 +0100
        Re: Dealing with timestamps from different timezones - general approach for basic saving? Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-30 10:04 -0400
          Re: Dealing with timestamps from different timezones - general approach for basic saving? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-30 22:38 +0100
            Re: Dealing with timestamps from different timezones - general approach for basic saving? Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-30 18:38 -0400
              Re: Dealing with timestamps from different timezones - general approach for basic saving? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-10-31 05:33 +0100
                Re: Dealing with timestamps from different timezones - general approach for basic saving? Jerry Stuckle <jstucklex@attglobal.net> - 2014-10-31 09:51 -0400
                  Re: Dealing with timestamps from different timezones - general approach for basic saving? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-01 09:31 +0100
                    Re: Dealing with timestamps from different timezones - general approach for basic saving? Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-01 09:31 -0400
                      drifted into ABUSE: Re: Dealing with timestamps bill <william@TechServSys.com> - 2014-11-01 11:21 -0400
                        Re: drifted into ABUSE: Re: Dealing with timestamps Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-11-01 17:04 +0100
                        Re: drifted into ABUSE: Re: Dealing with timestamps Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-01 21:32 -0400
                          Re: drifted into ABUSE: Re: Dealing with timestamps Tim Streater <timstreater@greenbee.net> - 2014-11-02 09:27 +0000
    Re: Dealing with timestamps from different timezones - general approach for basic saving? Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-29 01:50 +0000

#14423 — Dealing with timestamps from different timezones - general approach for basic saving?

Hey there,

I have a short question about internationalized systems and the saving of timestamps. 

Scenario:
Users from different countries post blod entries into a php-based system. The blog entries will have a created and a modified timestamp (actually a datetime-field in a MySQL-db).

What is the best approach to save the timestamp, so that the information when the "real" creation date will still preserved?

When a user from let's say Brazil views an entry from a user that posted from Hong Kong, he/she should see the date(time) in his/her "timezoned" timestamp.

My approach would be to save all dates/datetimes in UTC as a general information, and then apply the timezone-offset depending on the current viewer (e.g. the user that requests the blog entry). Otherwise I'd need to save the timezone(offset) for every entry in the DB, which could be useful, or overhead....


What are your approaches for real-life scenarios when dealing with users from different timezones? Any help is much appreciated...

[toc] | [next] | [standalone]

#14424

On 10/28/2014 3:42 PM, e.blumstengel@googlemail.com wrote:
> Hey there,
> 
> I have a short question about internationalized systems and the saving of timestamps. 
> 
> Scenario:
> Users from different countries post blod entries into a php-based system. The blog entries will have a created and a modified timestamp (actually a datetime-field in a MySQL-db).
> 
> What is the best approach to save the timestamp, so that the information when the "real" creation date will still preserved?
> 
> When a user from let's say Brazil views an entry from a user that posted from Hong Kong, he/she should see the date(time) in his/her "timezoned" timestamp.
> 
> My approach would be to save all dates/datetimes in UTC as a general information, and then apply the timezone-offset depending on the current viewer (e.g. the user that requests the blog entry). Otherwise I'd need to save the timezone(offset) for every entry in the DB, which could be useful, or overhead....
> 
> 
> What are your approaches for real-life scenarios when dealing with users from different timezones? Any help is much appreciated...
> 

The problem here is knowing what the user's timezone is.  You can tell
when the blog was posted, of course, and really don't care about the
user's timezone.  You can save it in any timezone you wish, but
typically it's either UTC or the timezone of your server.

But when retrieving the blog entry, you don't know the reader's timezone
(unless they've logged in and set it in their profile).  Your only real
choices here are to:

1. Ask for their timezone and save it in a cookie (an extra operation on
their part)
2. Use javascript to fetch the user's timezone and display it
accordingly (off topic in a PHP newsgroup)
3. Use a combination of #1 and #2 and set a cookie with the timezone,
but it won't work on the first page they display (because the javascript
doesn't run until after the page is displayed.  You would have to use
javascript to reload the page.
4. Display the time in a standard format (i.e. UTC) or, if your readers
are pretty much all U.S. based, something like EST/EDT or PST/PDT.

Each has its advantages and disadvantages; it's up to you to determine
which you wish to use.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14428

Jerry Stuckle wrote:

> But when retrieving the blog entry, you don't know the reader's timezone
> (unless they've logged in and set it in their profile).  Your only real
> choices here are to:
> 
> 1. Ask for their timezone and save it in a cookie (an extra operation on
> their part)

Or local storage.  For privacy, in a server-side session.  Could be in a 
database.

> 2. Use javascript to fetch the user's timezone and display it
> accordingly (off topic in a PHP newsgroup)

It would be the *system’s* timezone, which is why it is error-prone.

> 3. Use a combination of #1 and #2 and set a cookie with the timezone,
> but it won't work on the first page they display (because the javascript
> doesn't run until after the page is displayed.  You would have to use
> javascript to reload the page.

Not necessarily.  And there is no javascript.

<http://PointedEars.de/es-matrix>

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14432

On 10/30/2014 3:14 AM, the pedantic troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> But when retrieving the blog entry, you don't know the reader's timezone
>> (unless they've logged in and set it in their profile).  Your only real
>> choices here are to:
>>
>> 1. Ask for their timezone and save it in a cookie (an extra operation on
>> their part)
> 
> Or local storage.  For privacy, in a server-side session.  Could be in a 
> database.
>

And how are you going to do that unless they sign in?

>> 2. Use javascript to fetch the user's timezone and display it
>> accordingly (off topic in a PHP newsgroup)
> 
> It would be the *system’s* timezone, which is why it is error-prone.
> 

It is the user's system - not the server system.  Only you wouldn't know
what I mean.

>> 3. Use a combination of #1 and #2 and set a cookie with the timezone,
>> but it won't work on the first page they display (because the javascript
>> doesn't run until after the page is displayed.  You would have to use
>> javascript to reload the page.
> 
> Not necessarily.  And there is no javascript.
> 
> <http://PointedEars.de/es-matrix>
> 

There is javascript - and there are pedantic trolls.  You are at the top
of the list of the latter.

And you need to correct your nickname.  It's not your ears that are
pointed - it's your head.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14434

Jerry Stuckle wrote:

> [abuse] Thomas 'Pointed Head' Lahn wrote:
>> Jerry Stuckle wrote:
>>> 1. Ask for their timezone and save it in a cookie (an extra operation on
>>> their part)
>> Or local storage.  For privacy, in a server-side session.  Could be in a
>> database.
> 
> And how are you going to do that unless they sign in?

1. STFW for “Local Storage”.

2. Server-side (PHP) sessions set a cookie with a session ID, but the
   privacy-critical payload is stored on the server.  No sign-in necessary.
 
>>> 2. Use javascript to fetch the user's timezone and display it
>>> accordingly (off topic in a PHP newsgroup)
>> 
>> It would be the *system’s* timezone, which is why it is error-prone.
> 
> It is the user's system - not the server system.

*sigh*  I know.  Nobody but you, now, referred to the server in *that* 
regard.  The point here is, it would be not the user’s timezone, but that of 
the local computer system.  Big difference.

> Only you wouldn't know what I mean.

You know far, far less about me than you think.

>>> 3. Use a combination of #1 and #2 and set a cookie with the timezone,
>>> but it won't work on the first page they display (because the javascript
>>> doesn't run until after the page is displayed.  You would have to use
>>> javascript to reload the page.
>> Not necessarily.  And there is no javascript.
>> 
>> <http://PointedEars.de/es-matrix>
> 
> There is javascript […]

Only in the heads of wannabes who could not tell a property accessor from an 
Array initialiser, and an operator from different syntactical constructs.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14435

On 10/30/2014 5:38 PM, the troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> [abuse] Thomas 'Pointed Head' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> 1. Ask for their timezone and save it in a cookie (an extra operation on
>>>> their part)
>>> Or local storage.  For privacy, in a server-side session.  Could be in a
>>> database.
>>
>> And how are you going to do that unless they sign in?
> 
> 1. STFW for “Local Storage”.
> 
> 2. Server-side (PHP) sessions set a cookie with a session ID, but the
>    privacy-critical payload is stored on the server.  No sign-in necessary.
> 

And just how is he supposed to get the timezone from your answer?

A typical "Pointed Head" response - you don't know the answer but you
have to make a fool of yourself anyway.

BTW - what's wrong with storing the timezone in a cookie?  There isn't
any security issue here - if the user changes the contents of the
cookie, it will just display the wrong time for him.

>>>> 2. Use javascript to fetch the user's timezone and display it
>>>> accordingly (off topic in a PHP newsgroup)
>>>
>>> It would be the *system’s* timezone, which is why it is error-prone.
>>
>> It is the user's system - not the server system.
> 
> *sigh*  I know.  Nobody but you, now, referred to the server in *that* 
> regard.  The point here is, it would be not the user’s timezone, but that of 
> the local computer system.  Big difference.
> 

Yes, and I don't know about you, but people keep their local system
timezone to the one they want their time displayed in.

>> Only you wouldn't know what I mean.
> 
> You know far, far less about me than you think.
> 

I know far MORE than you do, obviously.  But this is just another
typical "Pointed Head" response.

>>>> 3. Use a combination of #1 and #2 and set a cookie with the timezone,
>>>> but it won't work on the first page they display (because the javascript
>>>> doesn't run until after the page is displayed.  You would have to use
>>>> javascript to reload the page.
>>> Not necessarily.  And there is no javascript.
>>>
>>> <http://PointedEars.de/es-matrix>
>>
>> There is javascript […]
> 
> Only in the heads of wannabes who could not tell a property accessor from an 
> Array initialiser, and an operator from different syntactical constructs.
> 

Only in your mind, Pointed Head.  The rest of the world knows better.

Now why don't you crawl back into your little hole.  But please don't
insert your head where the sun doesn't shine - the point might perforate
your colon.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14436

Jerry Stuckle wrote:

> […] Thomas […] Lahn wrote:
>> Jerry Stuckle wrote:
>>> […] Thomas […] Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>>> 1. Ask for their timezone and save it in a cookie (an extra operation
>>>>> on their part)
>>>> Or local storage.  For privacy, in a server-side session.  Could be in
>>>> a database.
>>> And how are you going to do that unless they sign in?
>> 
>> 1. STFW for “Local Storage”.
>> 
>> 2. Server-side (PHP) sessions set a cookie with a session ID, but the
>>    privacy-critical payload is stored on the server.  No sign-in
>>    necessary.
> 
> And just how is he supposed to get the timezone from your answer?

Those who can read and have not closed their mind have surmised by now that 
instead of saving the timezone *as provided by the user* in a cookie *as you 
proposed*, it could be saved in Local Storage or in a server-side session 
instead, whereas, with PHP at least, the session data could be held in a 
database.
 
> BTW - what's wrong with storing the timezone in a cookie?  There isn't
> any security issue here - if the user changes the contents of the
> cookie, it will just display the wrong time for him.

Once you have looked deeper into those issues, you will have realized that 
*any* personal information is a matter of *privacy*.  Security is a 
different concept that you were the first to mention here, confusing the 
issue.
 
>>>>> 2. Use javascript to fetch the user's timezone and display it
>>>>> accordingly (off topic in a PHP newsgroup)
>>>> It would be the *system’s* timezone, which is why it is error-prone.
>>> It is the user's system - not the server system.
>> *sigh*  I know.  Nobody but you, now, referred to the server in *that*
>> regard.  The point here is, it would be not the user’s timezone, but that
>> of the local computer system.  Big difference.
> 
> Yes, and I don't know about you, but people keep their local system
> timezone to the one they want their time displayed in.

Iff they are aware of the issue and able to do something about it.  That’s 
the point.
 
> Now why don't you crawl back into your little hole.  But please don't
> insert your head where the sun doesn't shine - the point might perforate
> your colon.

It is fortunate that your vocabulary forms an empty intersection with mine.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14437

On 10/31/2014 12:33 AM, the troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> […] Thomas […] Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> […] Thomas […] Lahn wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> 1. Ask for their timezone and save it in a cookie (an extra operation
>>>>>> on their part)
>>>>> Or local storage.  For privacy, in a server-side session.  Could be in
>>>>> a database.
>>>> And how are you going to do that unless they sign in?
>>>
>>> 1. STFW for “Local Storage”.
>>>
>>> 2. Server-side (PHP) sessions set a cookie with a session ID, but the
>>>    privacy-critical payload is stored on the server.  No sign-in
>>>    necessary.
>>
>> And just how is he supposed to get the timezone from your answer?
> 
> Those who can read and have not closed their mind have surmised by now that 
> instead of saving the timezone *as provided by the user* in a cookie *as you 
> proposed*, it could be saved in Local Storage or in a server-side session 
> instead, whereas, with PHP at least, the session data could be held in a 
> database.
>

Which still doesn't answer the question.  How does it get the timezone
from the user?  Does the user have to answer a question (another added
hurdle for the user to jump through)?

Getting it through javascript means the user doesn't have to answer a
question.  And how many users (besides yourself, of course) sets up
their system with a timezone other than the one they want to see the
time displayed in?

And you never said why it should be stored in local storage or
server-side instead of in a cookie.  And if it's held in a database, how
does the database entry get related to the user - other than through a
registration process (another hurdle).  And the database idea fails when
people travel to other timezones.

Your idea has more holes than a sieve.

>> BTW - what's wrong with storing the timezone in a cookie?  There isn't
>> any security issue here - if the user changes the contents of the
>> cookie, it will just display the wrong time for him.
> 
> Once you have looked deeper into those issues, you will have realized that 
> *any* personal information is a matter of *privacy*.  Security is a 
> different concept that you were the first to mention here, confusing the 
> issue.
>  

Show how storing a timezone in a cookie on the user's computer affects
privacy - and how storing it on the server is better.

>>>>>> 2. Use javascript to fetch the user's timezone and display it
>>>>>> accordingly (off topic in a PHP newsgroup)
>>>>> It would be the *system’s* timezone, which is why it is error-prone.
>>>> It is the user's system - not the server system.
>>> *sigh*  I know.  Nobody but you, now, referred to the server in *that*
>>> regard.  The point here is, it would be not the user’s timezone, but that
>>> of the local computer system.  Big difference.
>>
>> Yes, and I don't know about you, but people keep their local system
>> timezone to the one they want their time displayed in.
> 
> Iff they are aware of the issue and able to do something about it.  That’s 
> the point.
>  

Of course, you try to sidestep the question instead of admitting you are
wrong.  How many people (besides you, that is, because we know you don't
know how to change the time) set their computer to a timezone other than
the one they wish to view times in?  Even Windows makes it quite easy.

>> Now why don't you crawl back into your little hole.  But please don't
>> insert your head where the sun doesn't shine - the point might perforate
>> your colon.
> 
> It is fortunate that your vocabulary forms an empty intersection with mine.
> 

Yes, but then it's easy for anyone to form an empty intersection with an
empty set.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14441

Jerry Stuckle wrote:

> On 10/31/2014 12:33 AM, the troll Thomas 'Pointed Head' Lahn wrote:
>> Jerry Stuckle wrote:
>>> […] Thomas […] Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>>> […] Thomas […] Lahn wrote:
>>>>>> Jerry Stuckle wrote:
       ^^^^^^^^^^^^^
>>>>>>> 1. Ask for their timezone and save it in a cookie (an extra
           ^^^^^^^^^^^^^^^^^^^^^^
>>>>>>> operation on their part)
>>>>>> Or local storage.  For privacy, in a server-side session.  Could be
>>>>>> in a database.
>>>>> And how are you going to do that unless they sign in?
>>>>
>>>> 1. STFW for “Local Storage”.
>>>>
>>>> 2. Server-side (PHP) sessions set a cookie with a session ID, but the
>>>>    privacy-critical payload is stored on the server.  No sign-in
>>>>    necessary.
>>>
>>> And just how is he supposed to get the timezone from your answer?
>> 
>> Those who can read and have not closed their mind have surmised by now
>> that instead of saving the timezone *as provided by the user* in a cookie
>> *as you proposed*, it could be saved in Local Storage or in a server-side
>> session instead, whereas, with PHP at least, the session data could be
>> held in a database.
> 
> Which still doesn't answer the question.  How does it get the timezone
> from the user?  Does the user have to answer a question (another added
> hurdle for the user to jump through)?

See the markings above.  It was *your* idea, so *you* must answer that 
question.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14442

On 11/1/2014 4:31 AM, the troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> On 10/31/2014 12:33 AM, the troll Thomas 'Pointed Head' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> […] Thomas […] Lahn wrote:
>>>>> Jerry Stuckle wrote:
>>>>>> […] Thomas […] Lahn wrote:
>>>>>>> Jerry Stuckle wrote:
>        ^^^^^^^^^^^^^
>>>>>>>> 1. Ask for their timezone and save it in a cookie (an extra
>            ^^^^^^^^^^^^^^^^^^^^^^
>>>>>>>> operation on their part)
>>>>>>> Or local storage.  For privacy, in a server-side session.  Could be
>>>>>>> in a database.
>>>>>> And how are you going to do that unless they sign in?
>>>>>
>>>>> 1. STFW for “Local Storage”.
>>>>>
>>>>> 2. Server-side (PHP) sessions set a cookie with a session ID, but the
>>>>>    privacy-critical payload is stored on the server.  No sign-in
>>>>>    necessary.
>>>>
>>>> And just how is he supposed to get the timezone from your answer?
>>>
>>> Those who can read and have not closed their mind have surmised by now
>>> that instead of saving the timezone *as provided by the user* in a cookie
>>> *as you proposed*, it could be saved in Local Storage or in a server-side
>>> session instead, whereas, with PHP at least, the session data could be
>>> held in a database.
>>
>> Which still doesn't answer the question.  How does it get the timezone
>> from the user?  Does the user have to answer a question (another added
>> hurdle for the user to jump through)?
> 
> See the markings above.  It was *your* idea, so *you* must answer that 
> question.
> 

I answered the question in my first response.  But YOU never answered it
in YOUR response.  And you won't, because you can't - as usual, you have
no idea what you are talking about.

So once again you show your head is so far up your arse that you're in
danger of puncturing your colon with the point.  I really pity any
potential client suckered enough to hire you.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14444 — drifted into ABUSE: Re: Dealing with timestamps

Do you guys think that when you have drifted into exchanging 
personal invective you could change the RE to indicate that?

-bill

[toc] | [prev] | [next] | [standalone]

#14445 — Re: drifted into ABUSE: Re: Dealing with timestamps

bill wrote:

> Do you guys think that when you have drifted into exchanging
> personal invective you could change the RE to indicate that?

There are no invectives in *my* postings.

HTH

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#14446 — Re: drifted into ABUSE: Re: Dealing with timestamps

On 11/1/2014 11:21 AM, bill wrote:
> Do you guys think that when you have drifted into exchanging personal
> invective you could change the RE to indicate that?
> 
> -bill

Bill,

Just calling "Pointed Head" what he is known as in many newsgroups - a
pedantic troll.  And also calling him on his bad programming practices -
people need to learn GOOD programming practices - which he definitely
does not use (as is also known in multiple newsgroups).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14447 — Re: drifted into ABUSE: Re: Dealing with timestamps

In article <m341k1$6oo$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

> On 1/11/2014 11:21 AM, bill wrote:
> > Do you guys think that when you have drifted into exchanging personal
> > invective you could change the RE to indicate that?

> Just calling "Pointed Head" what he is known as in many newsgroups - a
> pedantic troll.  And also calling him on his bad programming practices -
> people need to learn GOOD programming practices - which he definitely
> does not use (as is also known in multiple newsgroups).

PointyHead seems to think he owns the groups he posts in, and
continually gives unnecessary orders to people to do this, that, or the
other. Perhaps Bill could persuade PH to stop abusing everyone.

-- 
"... you must remember that if you're trying to propagate a creed of 
 poverty, gentleness and tolerance,  you need a very rich, powerful,
 authoritarian organisation to do it."             - Vice-Pope Eric

[toc] | [prev] | [next] | [standalone]

#14425

On Tue, 28 Oct 2014 12:42:48 -0700, e.blumstengel wrote:

> What are your approaches for real-life scenarios when dealing with users
> from different timezones? Any help is much appreciated...

Apply UTC timestamps to everything, assuming the server knows what UTC is.

To display something to a visitor in a meaningful timezone for the 
visitor, you need to get the visitor's timezone, and that's not part of 
the normal http protocol.

So you can either display posts as UTC, play guess the timezone based on 
the visitors IP (which may indicate their location), use javascript to 
detect the local timezone in the browser and convert the timestamp on the 
fly, ask the user what timezone they want things displayed in, or use 
javacript to obtain their timezone in an ajax exchange.

If you know their timezone on the server (you used javascript to acquire 
it using an ajax exchange, or they told you it) then you can send them a 
cookie and use the cookie in future (until it expires), and obviously you 
can also hold it in session storage for the current session.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web